Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
PHP Open Source News

PHP 5.4 Released 209

mikejuk writes "PHP 5.4 has been released, along with a new version of Zend Framework. It has a number of optimizations that make it faster and smaller (early estimates say 10-20% faster), a built-in webserver for testing purposes, and features that had been destined for PHP 6.0. The big addition from the now-crashed PHP 6.0 project is Traits, which are sort of a cross between a class and an interface, bringing some of the advantages of multiple inheritance to PHP. The full changelog and download page are both available."
This discussion has been archived. No new comments can be posted.

PHP 5.4 Released

Comments Filter:
  • by Barbara, not Barbie ( 721478 ) <barbara@hudson.gmail@com> on Saturday March 03, 2012 @09:15PM (#39235237) Journal

    a cross between a class and an interface,

    ... having php adopt a bad idea from Java and making it worse? Wouldn't we be better off actually having static typing instead?

    • by Daniel Dvorkin ( 106857 ) on Saturday March 03, 2012 @09:41PM (#39235367) Homepage Journal

      Java interfaces are essentially a fancy form of documentation. Traits sound like they provide actual functionality.

      As for static typing ... oh, never mind. If you prefer static typing, by all means, use a language that has it. Also bear in mind that static typing != strong typing; a lot of people who complain about the lack of the first really seem to be talking about the second.

      • Java interfaces are essentially a fancy form of documentation.

        They are also a contract (although I admit not the fanciest).

        • They are also a contract

          And, IMO, a contract is a fancy form of documentation. If you can't implement any functionality in it, it doesn't do anything that a careful check of the program against the design specs can't also accomplish. I'm not saying interfaces are useless, but I wish people would stop saying "we don't need multiple inheritance, we've got interfaces!" when they don't do anywhere near the same thing.

      • by siride ( 974284 )

        You don't understand interfaces. They aren't just documentation. They allow you to actually do things that you wouldn't be able to do otherwise. Let's say you have an IDisplayable interface that provides some functions that let you pretty-print the contents of the object. Any object that belongs to a class that implements this interface can be assigned to a variable of type IDisplayable. The only methods you can call on a variable of that type are the pretty-print methods, but that's okay, because that's al

        • You don't understand interfaces. They aren't just documentation. They allow you to actually do things that you wouldn't be able to do otherwise. Let's say you have an IDisplayable interface that provides some functions that let you pretty-print the contents of the object. Any object that belongs to a class that implements this interface can be assigned to a variable of type IDisplayable.

          Interfaces are just a documentation in a dynamically typed language like PHP, since variables don't have types. The only other thing they give you there over duck typing is the ability to do instanceof checks.

          • Dynamic/static and strict/weak are orthogonal in general. A dynamically typed language could just as easily verify that all necessary methods defined by an interface are implemented by an implementation -- it's just that the check would happen at run-time rather than compile time.

          • Not true on so many levels. PHP variables do have types, you just don't have to declare them. If you don't understand that you'll be very confused when your integer becomes a float due to overflow and suddenly your output contains a bunch of numbers after the decimal. You can use type hinting on a method signature to make certain that the variable you get implements the interface you expect, exactly as you would in a statically typed language. If you aren't doing type hinting in PHP you're really ignori
          • by siride ( 974284 )

            You said Java interfaces. In Java, they are not documentation. In PHP, you are mostly correct, as I indicated at the end of my post.

            • by siride ( 974284 )

              You aren't the guy I was replying to, but *he* said "Java interfaces" and I responded to that.

      • by msobkow ( 48369 )

        Interfaces are a method contract, not "fancy...documentation."

        If you think interfaces are "just" documentation, you don't know SHIT about OO programming. Sorry dude, but your perspective is like saying that C/C++/C#/Java are "just" big macro assemblers because everything eventually runs on a CPU.

    • by tomhath ( 637240 )

      having php adopt a bad idea from Java and making it worse?

      More like understanding what went wrong in Java and not making the same mistake again.

      Wouldn't we be better off actually having static typing instead?

      If you want a static typed language and all the tedium that goes with it, use Java. If you want faster development and less code, use a dynamically typed language.

      • I'm a dynamic languages guy, but to be fair, that tedium is Java's fault, not the static typing. A good typing system will have inference.

        factorial x = if x == 0 then 1 else x * factorial (x-1)

        This is statically typed code in Haskell, but as you can see there are no type declarations to be seen.

        • by arth1 ( 260657 )

          hmm, I'm not sure that duck typing qualifies as static typing. I mean, can you infer from the above whether x can be a float or not?

          • It's parametric polymorphism (a generic programming feature), not duck typing. Essentially, the compiler will generate (on compile-time, not runtime) two different instances of the factorial function, one for x as a float and one for x as an int.

            If factorial is called with an invalid type (one for which the compiler can't generate a valid implementation of the function), that error will be detected at compile time.

    • a cross between a class and an interface,

      ... having php adopt a bad idea from Java and making it worse? Wouldn't we be better off actually having static typing instead?

      Yes, a class is a terrible concept that must be abolished at once!

      What are you criticizing exactly?

    • Frankly, why don't they seize the opportunity of PHP6 to rewrite~redesign that language, focus on lib functions names consistency and introducing true indexed arrays, and nested functions (currently nested functions behave the same as top level funcs, ridiculous), for starters.
      • I'd add getting rid of GLOBAL declarations inside functions, implementing proper variable scoping rules, and no auto-vivication of variables to that list. It needs a real clean-up.
        • Creating some consistency in needle/haystack vs. haystack/needle order in relevant built in functions would be high on my list of things for them to fix.

          Making namespacing not suck balls would be nice.

          Personally, I like "global" declarations in functions/methods--can't leave all the newbie-tripping-up fun to Python's explicit "self" argument, can we? :-)

          • needle/haystack vs. haystack/needle

            Oh yes, this! I cannot imagine someone writing in C some PHP functions not implementing this mess on purpose. How come...

    • Traits are coming in Java 8 with the addition of default method implementations to interfaces.

    • by rev0lt ( 1950662 )
      Multiple inheritance isn't a Java concept. It's a OO concept, older than java itself. Also, PHP isn't a OO development language, but a scripting language that supports OO constructs, and the latest releases have been focusing hard on modern OO funcionality. If you don't like a given feature, don't use it. Try do something in java that doesn't involve instantiation of an object.
      • I never said multiple inheritance was a Java concept. In fact, I think one of the mistakes in Java was *not* supporting multiple inheritance, just like another one was stuffing everything into classes and objects.

        Multiple inheritance in c++ is simple. People who think otherwise need to sit down for 15 minutes and review it to see how much better it is than interfaces.

        • IIRC, not supporting multiple inheritance was one of the primary motivations for Java. Multiple inheritance (again, IIRC) makes it impossible to avoid ambiguities that a compiler can not resolve, thus making it easy to write programs that can be very difficult to debug. I haven't looked at this stuff for 20 years, so I don't recall perzackly. Not supporting MI meant the size of the Java compiler a small fraction of the size, and much more reliable. But others here can speak to this far better than I.

  • by bogaboga ( 793279 ) on Saturday March 03, 2012 @09:35PM (#39235325)

    Telling us readers how it (the new PHP) measures up to the competition would have been better and more informative.

    So, let me bite: How does this new release measure up to the competition?

    • by Anonymous Coward on Saturday March 03, 2012 @09:46PM (#39235397)
      well, it's PHP. And the competition is not PHP. So the competition wins.
  • by PCM2 ( 4486 ) on Saturday March 03, 2012 @09:44PM (#39235385) Homepage

    What synchronicity! Just the other day I was thinking about the beautiful and elegant poetry that is PHP's syntax and standard library, and I was saying to myself, "You know... if there's one thing PHP needs, it's multiple inheritance."

    • Re:Oh good Lord (Score:4, Insightful)

      by CastrTroy ( 595695 ) on Saturday March 03, 2012 @10:11PM (#39235535)
      I don't even know why they added object oriented features in the first place. It's really hard to bolt something like Object Oriented features on to language that never had them. Not to mention that having half the standard library in OO and half in procedural just makes everything an even bigger mess. PHP would probably be a lot cleaner and more palatable had they never tried to add objects in the first place.
      • I never saw the need for OO in PHP either. I think the language was faster, and made more sense, without it.

    • Don't be too harsh about PHP. It's a rough language that allows almost anybody to write rough programs that eventually give rough results. A democratic language...
    • What synchronicity! Just the other day I was thinking about the beautiful and elegant poetry that is PHP's syntax and standard library, and I was saying to myself, "You know... if there's one thing PHP needs, it's multiple inheritance."

      I once asked the PHP developers at ZendCon about why they don't gradually clean up the standard library, and the impression that I got was that backwards compatibility is a top priority for PHP and Zend.

      While I personally do prefer the Python way of planning gradual changes to the standard library along with migration paths I do also see the strength of leaving things the way they are. Fortunately there is more than one language to use for web develiopment if PHP won't float your boat.

  • by lanner ( 107308 ) on Saturday March 03, 2012 @09:46PM (#39235391)

    PHP has always been a security nightmare. Can anyone speak about security issues, enhancements, etc, that us sysadmins should know about?

    • Re:PHP security (Score:5, Informative)

      by CastrTroy ( 595695 ) on Saturday March 03, 2012 @10:02PM (#39235479)
      PHP has had some security issues, but they can largely be avoid. First, always use parameterized queries (prepared statements) using PDO or MySQLi. Register Globals [php.net], which was a big problem in the past has been removed in 5.4. Most of the security problems I'm aware of can be summed up in those two things. I think the reason it has such a bad reputation is that it has so many newbie developers on it, and because there are a lot of bad tutorials out there (possibly written by newbies) that show bad practices, such as not using parameterized queries.
      • One thing that I found myself curious about earlier this week.

        I was trying to do up a proof-of-concept demonstration for the semi-PHB to explain the risk of SQL injections, and I couldn't make it work with MySQL (I know, I know...).

        Is the fact that PHPs built in mysql_* function set doesn't do compound statements (multiple SQL queries in a single string/function call) a bug or a feature?

        • by Billly Gates ( 198444 ) on Saturday March 03, 2012 @11:22PM (#39235767) Journal

          Here is my code from my login page in php 4 that is super secure

          $query_login="select * FROM user";
          $result_login = mysql_query($query_login) or die("Your passwrod is might be bad I think"); //$login_check = mysql_num_rows($result_login);
          while($row=mysql_fetch_array($result_login))
          {
          $username=$row["username"];
          if ($username==$username1)
          {
          echo "";
          echo "window.location.href='login_error.php?rec=qq';";
          echo "";
          exit;
          }
          }

          • Dear god I hope you're not serious
            • It's because of such examples that people are saying that PHP is a security nightmare. Truth is, if you know what you are doing, it isn't worse than anything else. As for the language itself, compare it to the Java virtual machine from SUN, which many think (IMO, wrongly) that is a much more professional language. Now count last year's CVE against Java, and compare them to the ones of PHP, then make your own idea...
        • by armanox ( 826486 )

          It's my understanding that it's a feature for exactly that purpose (avoiding injection attacks).

        • by devent ( 1627873 )
          Why were EGPCS (Environment, GET, POST, Cookie, Server) variables registered as global variables in the first place anyway? Who could think of it as a nice feature to just register variables from outside of the application? I think that speaks a lot of the environment of PHP and the community behind it.
      • by devent ( 1627873 )
        Why were EGPCS (Environment, GET, POST, Cookie, Server) variables registered as global variables in the first place anyway? Who could think of it as a nice feature to just register variables from outside of the application? I think that speaks a lot of the environment of PHP and the community behind it. PS: Sorry I reply to the wrong post.
      • IIRC it still doesn't provide a secure random number generator as part of the core language. Given it's target application often requires generating things like session IDs that if guessed can allow session hijacking that seems pretty inexcusable to me.

  • It'd be really nice if PHP would add some nice template features that Smarty / Twig have. (elseforeach, simple echo htmlentities construct ?)

    The developers of PHP are so focused on becoming a real language that they've forgotten what PHP is all about: templating! There's no real focus on adding template features (ok... I don't have to type array now...).
  • Goody! Just another 5 years 'till it hits the production servers now.

  • by wimg ( 300673 ) on Sunday March 04, 2012 @12:31AM (#39236077) Homepage

    If you want to get your code compatible, a start is to scan it automatically : https://github.com/wimg/PHPCompatibility - just released for 5.4 as well :-)

    • I just tried it, and however I put it, I always got loads of "Spaces must be used to indent lines; tabs are not allowed" or "Line indented incorrectly; expected at least 4 spaces, found 1". How do I tell phpcs to behave as it should, and only warn about important things (eg, in my case, only check 5.4 compatibility)? I tried "phpcs --standard=PHPCS --sniffs=PHP .", but then I get: PHP Notice: Undefined offset: 1 in /usr/share/php/PHP/CodeSniffer/CLI.php on line 328, PHP Notice: Undefined offset: 2 in /usr
  • by greywire ( 78262 ) on Sunday March 04, 2012 @12:34AM (#39236093) Homepage

    I've been waiting for traits in php (and thus php 5.4 when they finally decided to put traits into it) for some time now.

    Think of traits not as really an extension to the object oriented features (alternative to multiple inheritance..) but as a kind of language assisted cut and paste with conflict resolution.

    Because that's what it is. Traits are "flattened" at run time. Their methods become methods of the class where the trait is used, and work exactly like they were defined there to begin with. If there is a collision in the naming, you can specifically resolve that with language syntax.

  • Can't they just release a new version of PHP that doesn't break backward compatibility. Microsoft was able to do this with classic ASP and for the most part .NET for many years now. Sun and Oracle figured out how to do it with Java. Why can't Zend do it?

    I'm tired of having features disappear. Yeah, magic quotes and safe mode were stupid. Maybe if they actually designed the damn language rather than throw in crap all the time this wouldn't happen.

    This is the single biggest issue I have with PHP.

    • If you think that PHP === Zend, then you are mistaking. Zend aren't the ones behind the language itself, which is made in an open source way. As for compatibility, there's not much that changed, and it's very easy to fix. If people can't maintain their code, then it's not worse using what they do.
      • by laffer1 ( 701823 )

        This is ridiculous. You think every time a SECURITY update comes out I should modify my code for every app I've ever written. I don't think so.

        See that's what this is, a security update. They don't support old versions of PHP so it's a forced upgrade. Thus backward compatibility is important. Yeah, there's only a few things here and there between individual releases, but consider someone hosting on CentOS and then a new CentOS comes out. Suddenly they're 2 major releases ahead. Nothing works.. the sys

  • GRRR. "extends" was for inheritance, "implements" was for interfaces, so why wasn't "uses" chosen for traits, instead of "use"?
     

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Working...