PHP 5.5.0 Alpha 6 - Released | Hacker News Reader

PHP 5.5.0 Alpha 6 - Released

php.net

96 pointsJeremy102671 comments

Open articleView on HN

For those wondering what the new features for PHP 5.5 are at this point, here is a small (not complete) list:

Large language changes:

* Generators and coroutines (https://wiki.php.net/rfc/generators by me)

* `finally` blocks (https://wiki.php.net/rfc/finally by laruence)

Syntactic sugar:

* Support for function calls in `empty()` (https://wiki.php.net/rfc/empty_isset_exprs by me)

* Support for `list()` in foreach (https://wiki.php.net/rfc/foreachlist by laruence)

* Constant array/string dereferencing (https://wiki.php.net/rfc/constdereference by laruence)

* Getting the fully qualified class name using `ClassName::class` (https://wiki.php.net/rfc/class_name_scalars by ralph)

Standard library:

* Simplified password hashing API (https://wiki.php.net/rfc/password_hash by ircmaxell)

* `hash_pbkdf2()` function (https://wiki.php.net/rfc/hash_pbkdf2 by ircmaxell)

* DateTimeImmutable, which is an immutable variant of DateTime (by derick)

Key anti-features (aka BC breaks):

* Dropped Windows XP and 2003 support (by pierre)

* ext/mysql deprecated (https://wiki.php.net/rfc/mysql_deprecation by aharvey)

* preg_replace /e modifier deprecated (https://wiki.php.net/rfc/remove_preg_replace_eval_modifier by me)

* Logo GUIDs removed (by ajf)

For the beta 1 (the next planned released) at least two more things are planned:

* Bundling of ZendOptimizer+ (https://wiki.php.net/rfc/optimizerplus by zeev)

* Allowing non-scalar Iterator keys in foreach (https://wiki.php.net/rfc/foreach-non-scalar-keys by me)

Are ZendOptimizer and APC meant to cohabitate in the core, or is the former going to replace the later ?

Any news on object literals $o = {'abc': 456}; and scalar type hint ?

Thanks for all the hard work, improvement in the language in 5.3 and 5.4 were awesome.

ZO+ will replace APC, only the user-cache from APC will be left (see also this comment: http://news.ycombinator.com/item?id=5343883).

Object literals and scalar type hints won't be in 5.5. Scalar type hints may be in the next version (it's a rather tricky topic). For object literals I don't see reason to add them at all (in PHP you can just use arrays ^^).

> in PHP you can just use arrays ^^

Which thankfully aren't as painful now!

    $cfg = [
        'path' => '.',
        'mask' => 655
    ];

Otherwise, if we still had to write "array" each time, I'd be more supportive of the object-literal, although I do think there's value in the literal but mostly to make the language similar to other languages with similar constructs (js, py).

With arrays you would have to do:

    $o = (object)[
        'foo' => 'bar'
    ];

Personally I think there should be a way to create objects right away instead of having to cast an array. Maybe there is a good reason all together for not using objects but I very much prefer typing $var->field instead of $var['field'].

Sure, but this still doesn't work:

  $o = (object)[
      'foo' => function(){ print 'bar'; },
  ];
  $o->foo();

You have to do it this way:

  call_user_func($o->foo);

Or this way:

  $foo = $o->foo;
  $foo();

Which doesn't work when foo is defined as a class method.

I believe by design it will always be: $foo = $o->foo; $foo();

Using __get/__set behaves the same way. Let's say $o is of SomeType that defines those magic methods. You can have a function foo on that type that is defined as a public method.

    $o->foo(); // the actual instance method
    $o->foo = function() { print 'bar'; };
    $o->foo(); // same instance method
    $foo = $o->foo;
    $foo(); // prints bar

In the case of StdClass it might be possible to do it your way where foo could be callable ($o->foo()) but I can see why they wouldn't allow this in order to keep things consistent.

Edit: It also behaves the same way if you assign a function to a public field of a class (I'm using 5.4) so I actually support not allowing a method to be directly callable in this fashion because this would be the only case where this behavior would occur.

Frankly, it would be infinitely better to be able to write:

    $data = {
        firstName: "John",
        lastName: "Smith",
        age: 25,
        address: {
            streetAddress: "21 2nd Street",
            city: "New York",
            state: "NY",
            postalCode: 10021
        },
        phoneNumber: {
            home: {
                number: "212 555-1234"
            },
            fax: {
                number: "646 555-4567"
            }
        }
    };

Rather than the awkward and verbose:

    $data = (object) [
        "firstName" => "John",
        "lastName" => "Smith",
        "age" => 25,
        "address" => (object) [
            "streetAddress" => "21 2nd Street",
            "city" => "New York",
            "state" => "NY",
            "postalCode" => 10021
        ],
        "phoneNumber": (object) [
            "home" => (object) [
                "number" => "212 555-1234"
            ],
            "fax" => (object) [
                "number" => "646 555-4567"
            ]
        ]
    ];

JSON is everywhere these days, supporting object literals is a very, very big deal; I understand which features to implement are handpicked very carefully so as not to clutter more the core, but we are talking about making the life of devs who use and write JSON more difficult, and that happens to be lots of folks.

Telling people to use arrays and be done with it is the equivalent of implement a strpos function that may only accept a string that's 5 characters long — yes, theoretically you can work with that splitting your strings, but that's time consuming and a inconsistent behaviour (why would 10 character long strings be less of a citizen than 5 char long ones?)

JSON, JavaScript Object Notation. How does it make sense to write PHP in Javascript syntax, when PHP has its own defined syntax?

Because 1) PHP syntax for object literals is non-existent 2) JSON is used in many more places than just Javascript and 3) the syntax of JSON makes sense; it's compact, human readable and easy to write. I'm not suggesting copying it 1:1 verbatim, but something close to JSON would definitely be an improvement. See for example how MongoDB uses a JSON-like syntax to great effect.

If for no other reason than ':' is easier to type than '=>'?

Hell will surely descend upon me, but I'd vote for having it be syntactic sugar for => in general.

You can already use the js-style shorthand inside of Twig templates, and I've been caught absentmindedly forgetting to switch to the 'proper' way for raw php now and then. And I would like to never need to even touch the shift key when having to write out an array or an object but even JSON won't let you do that. It's a step in the right direction, though.

I feel like there are dark factors at play for dropping the XP support. Although the most thorough discussion of it is at http://programmers.stackexchange.com/questions/177732/why-wa..., the conspiracist in me says that Microsoft (pierre's employer) pressured him to drop support - even though it wasn't entirely necessary to do so.

That's a good catch, and the justification was a little soft. But would you blame them?

Frankly, I'm irritated at them for dragging their heals on getting the PECL4Win back up and running (and the lack of updates to http://downloads.php.net/pierre/ doesn't help matters.)

Since I've moved to the camp of "You developing PHP and use Windows? Let me show you how to setup Vagrant" I've become less concerned about the state of PHP & Windows. I just won't tolerate when people say PHP dropping XP support is a good thing (which the OP wasn't saying, but some have.)

DLLs for PECL exts are currently available here: http://windows.php.net/downloads/pecl/ Not for all of them, but some of the more important ones. If you want something added to the list it's usually as simple as pinging Pierre on IRC :)

Someone should update the "In the meantime, some extensions can be found here." link on http://windows.php.net/, then.

The answers in that thread seem to be reasonable. XP is a decade-old OS, we should be glad that it will finally pass on April 2014. Supporting multiple operating systems takes time, especially for one that old. At some point it's best to move on.

If your company is affected by lack of XP support in this PHP build, it should be a temporary convenience at worst. What are your plans to migrate off XP over the next year? As of next April there will be no patches or security fixes coming for XP. Is your company planning on paying Microsoft for continued support, or will it negotiate extended XP support in return for buying company-wide Windows 8 licenses and start the ride over again?

I suspect that many of the people using XP today are frozen and wouldn't upgrade their PHP anyway, for the same reasons they're using XP and IE6. They either don't want to change their software because of cost/risk issues or the people who wrote it moved on years ago and they have no idea how it works.

I think you're right about the reasons for not upgrading. For orgs still using IE6 and XP, statistically it's very likely they're not going to be doing new development in PHP 5.5. (statistics pulled from thin air based on 15 years of experience with PHP and orbs who use it).

There's not been any security patches for PHP 4 for many years, but people still use it. Those same sorts of orgs will continue to use stuff out of date and unsupported for any number of reasons. Catering development processes around an increasingly small number of users doesn't make sense.

Regarding XP support; i'm not invested in this discussion, but the code has #defines for NETWARE[1], riscos[2], and even CRAY[3] in it... The last NetWare and RISC OS releases were (surprisingly to me) only 3 years ago, but surely XP is even now a much bigger deployment target? How often does the CRAY code get tested?

1. http://lxr.php.net/search?q=&defs=&refs=NETWARE&...

2. http://lxr.php.net/search?q=__riscos__&defs=&refs=&#...

3. http://lxr.php.net/search?q=CRAY&defs=&refs=&pat...

Hey, great work on that generators patch! Very well documented. It's been years since I wrote PHP but it's nice to know that if I have to at some point I'll have some things I like from Python and other languages available to me now.

Good stuff nikita, keep up the great work. I also vote for getting object literals added (it will be a great addition to the array literals).

This is at best meta, or at worst off-topic, but I have to say with 30+ comments at the moment, this is one of the best post/discussions I've read on HN with PHP as a main focus so far - technical, no flaming, some good insights and links. Thanks everyone :)

This won't add much either. I was kind of hoping for a flame-war but the feedback proved to be much more interesting than reading old clichés.

I'd like to get a sense of how often the PHP community tends to upgrade languages and frameworks for legacy products. Always/Never? Anyone care to provide some anecdote?

For example, I have two Rails apps that are running on Rails 2.2.x, so yeah, they're way behind, and I feel some sense of urgency to upgrade them soon... but I believe I am an outlier in the Ruby/Rails community in the sense that I am not upgrading all the time.

PHP tends to remain backwards compatible for a few major versions. Right now PHP has stable recent releases of 5.4 and 5.3. There is a bunch of older (5.2 and lower) PHP installs running around the web as well, since many cheap shared hosts aren't quick to update their installs.

We keep up to date on the build version, but the first decimal version (4 in 5.4, is that considered the minor version?) usually involve at least some backward-incompatible changes, so there is usually a need to test the codebase against new minor versions.

Personally, I always wait at least one year before upgrading PHP. There are always segfault or security issues or odd problems in a 5.x.0 release. It's around 5.x.4 that it becomes just stable enough to use.

About a month or two before I decide to upgrade I run the newer version locally while I'm developing (but being sure to not use any newer features). This usually weeds out any major incompatibilities and fix new warnings.

That said, I'm running 5.3 in production and have no real plans to upgrade to 5.4 anytime soon.

>That said, I'm running 5.3 in production and have no real plans to upgrade to 5.4 anytime soon.

May I ask: why not?

There is no real compelling reason for me to upgrade. The short array syntax is nice but it's not worth spending a day or more interrupting everyone's dev environments and building packages and introducing (potential) instability into something that I live off of.

You build the packages yourself? Is there a special reason why you need to do this?

Consistency. I use the system packages right now and Ubuntu does some tricks with the config that I'm used to.

Can you be more specific?

If you want to see the patches go into the Debian/Ubuntu packages, run apt-get source php5 and look at the php5-$version/debian/patches directory. The build process uses a quilt wrapper (dh_quilt_patch) to apply them in the correct order. There are patches for building (in general or for a specific architecture), segmentation faults, security issues, manual pages and very few configuration changes (mostly just FHS compliance).

That's pretty much exactly what I try to do. I grab the sources for the package and upgrade the underlying php version. I usually have to grab the PHP sources from a newer version of Ubuntu and modify it until it builds.

I've BTDT and it's tedious at times. Try this PPA: https://launchpad.net/~ondrej/+archive/php5

Fedora users have it easy, the packages there are mere days behind: https://admin.fedoraproject.org/updates/php

With a bit of experimenting you can easily do a network install of a headless Fedora/SL/CentOS in KVM using virt-install and a kickstart file. Use filesystem passthrough to access your source files, run php-fpm and configure its address as a backend in your web server. Keep SELinux enabled, but adjust it to your needs using setsebool if necessary.

That first link looks like exactly what I need, thank you!

I've tried Fedora in the past. I found it unstable and broken and I don't like RPM very much. It's undoubtedly improved since I last tried it (c. 2005-2006) but I don't miss RPM at all.

RPM is fine, I'm more worried about Journald, Systemd and the like. The programs they replace are much more elegant and simple by design.

CPU usage and memory consumption are cut by a third at worst and cut in half at best, personally I find that to be pretty compelling. It's a minor performance improvement but it's basically free.

Also on 5.3. I'm encoding my php files with zend guard, and they don't support php 5.4 yet, which is ironic given that it's zend.

Right now I'd say the only major "jump" that exists is the one between PHP 4 (released +10 years ago) and PHP 5. Other than that, apps are largely backwards compatible between 5.x versions, except for a few minor changes that no dev really stresses about.

The thing about PHP is that since it's massively used around the net, rather than forcing devs to catch up with the language, PHP devs themselves try as much as possible not to break backwards compability. Which in many ways is a pity, but that seems to be the direction of the language at the moment.

Actually, I would call 5.3 as a fairly major jump - namespaces, closures (Lambda/anonymous functions), late static binding, const's allowed outside of classes. There are several popular PHP frameworks that require v. 5.3+. Some people even go so far as to call the 5.3.x branch “php 6 without Unicode”.

Yes but most, if not all, PHP 5.2 code runs on PHP 5.3 without modification.

I usually upgrade as soon as it's stable. There has never been a downside as far as I can remember, because the old stuff usually just keeps on working. Whether that's been good for the language itself is debatable, but I imagine it sure helped adoption since they almost never break anything when they push out a new version.

As recently as this week, I came across a production server that was running PHP 4.4.x. A lot of popular apps continue to be written with PHP 4 compatibility in mind, which really hinders their ability to clean up bad code. Security updates for PHP 4 have been non-existent for several years already, so I try to stay away from these machines. Well, actually, I think some Linux distros (Red Hat?) still offer security updates for PHP 4, or did so until quite recently, but I can't remember the exact versions/dates.

A large number of web hosts still run PHP 5.2.x, while many have migrated to PHP 5.3. My last PHP 5.2-based client moved to a PHP 5.3-enabled web host a few weeks ago, so I'm finally free to use namespaces and closures.

Debian Stable and Ubuntu LTS are currently on PHP 5.3.x, which I suspect is partially responsible for the lack of PHP 5.4 adoption.

As for myself, I'm planning to rebuild my Ubuntu LTS dev box when Mint 15 comes out, so that's when I'll be upgrading to PHP 5.4. No need to hurry when none of my clients can use it anyway.

Dreamhost, as a shared hosting provider, has within the last month rolled out the option of PHP 5.4 on all their servers.

I wish all hosting providers would make newer versions available, then maybe open source projects would move with the times, and start bringing everyone up to date.

It should be noted that the release of 5.5.0 could be delayed a bit, due to the late addition of Zend Optimizer+ [0] (an opcode cache) being included into the core release like APC.

However there's a lot of arguing on php.internals about whether or not the right number of votes was reached (based on a not-specific-enough RFC on voting) so it may not even make it in.

[0]: http://files.zend.com/help/Zend-Server-Community-Edition/con...

So is Zend Optimizer meant to replace APC altogether, or just co-exist with APC? I've been using APC quite extensively assuming it would make it into the core eventually.

Besides opcode caching, APC provides shared key-value storage. I don't really see why they chose Zend over APC as a standard opcache. Also, they are incompatible and cannot run together.

The RFC for including ZO+ outlines some possible reasons: https://wiki.php.net/rfc/optimizerplus#advantages_of_optimiz...

That's why I asked, I really hope they ship APC within the core aswell if Zend Optimizer doesn't provide a data store. To be honest, I find the data store that APC provides way more important than opcode caching.

We will provide a separate extension (currently called "apcu") which contains only the user-cache part of APC. ZO+ and that extension together should behave the same way as APC currently does. This will actually work even better, because both components will be completely separate (the shared cache had fragmentation issues in APC.)

ZO+ was chosen over APC because it is more stable. ZO+ is (more or less) PHP 5.5 compatible already, whereas APC still tries to cope with 5.4 compatibility.

That's great, thanks for sharing.

Yes, it would replace APC. Unless you are using the user-caching of APC it should not affect you.

Wow, that's just silly then. The user caching part of APC is practically the sole reason I use it; it's by far the fastest (non-distributed) caching mechanism available for PHP right now, several orders of magnitude faster than memcache or redis since the round-trip time is zero.

Is that what you've found running memcache/redis on the same server? I've never actually used APC for user-caching.

Yes, YMMV depending on your environment, but I did test this carefully before making the decision to use APC for data caching wherever possible. IIRC I saw up to thousands of fetch/store operations in just 1ms using APC; but I'd suggest you to benchmark it on your own and judge by yourself.

Are you sure about that? I'm getting better performance with XCache, and it has everything that APC has plus some other useful features like deleting keys by prefix.

If anyone wants to try Zend Optimizer+ I threw together a control panel for it, which it was missing compared to APC:

https://gist.github.com/ck-on/4959032

I've found Optimizer+ has a few shortcomings, like no way to delete individual files from the cache, it's an all or nothing reset if you turn off file stat.

However it's definitely a bit faster than APC, at least 10% in most cases because of its multiple optimization passes.

Any noteworthy changes on 5.5 overall? I'm happy the language is moving forward with a seemingly faster traction than before (github effect?), but I haven't heard of any game changing feature getting implemented yet since quite a while. Still waiting for a object literals syntax myself.

https://raw.github.com/php/php-src/php-5.5.0alpha6/NEWS

The new changes I'm looking forward to are the password hashing API, scalar type hints and generators.

I'm also looking forward to 3 things that AREN'T going to be there: register_global, safe mode, and magic_quotes

Wow, those are finally going away? It's almost like the end of an era. Cool.

They were removed in 5.4 [1]

[1]http://www.php.net/manual/en/migration54.incompatible.php

I too am looking forward to the new Password Hashing API. Having quick ability to hash and verify a password should save a fair bit of time in the long run.

The password hashing stuff should be really nice in the long run--at least when it's widely used.

PHP in particular seems to have a lot of bad home brew implementations out there, so it'll be nice to have a better default.

In the meantime, I really enjoy using Marco Arment's Bcrypt PHP class: https://gist.github.com/marcoarment/1053158

Bcrypt? It's all about scrypt these days. http://stackoverflow.com/questions/10149554/are-there-any-ph...

There is a PHP 5.3.7+ implementation of the password API here: https://github.com/ircmaxell/password_compat

It seems to continue the PHP 5.4 vein in that it adds some syntactic shortcuts and some niceties that make it a bit easier / cleaner to read and write.

Personally I'm pretty happy with traits and array dereferencing against function returns. The new array literal syntax is nicer and more like other languages, in that you don't have to wrap everything with array(), instead just use the [] syntax.

Feature-wise 5.4 added traits and 5.5 has generators.

http://www.php.net/manual/en/migration54.new-features.php

http://www.php.net/manual/en/migration55.new-features.php

Does someone know how the test suite works? The way I understand [0] there currently 66 failing tests for the 5.5 line. Is this correct?

[0] http://gcov.php.net/viewer.php?version=PHP_5_5

Reply on news.ycombinator.com