
PHP 5.5.0 Alpha 6 - Released - Jeremy1026
http://php.net/archive/2013.php#id2013-03-07-1
======
nikic
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)

~~~
ecaron
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...](http://programmers.stackexchange.com/questions/177732/why-was-support-
for-windows-xp-dropped-in-php-5-5), 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.

~~~
dmethvin
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.

~~~
mgkimsal
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.

------
mgkimsal
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 :)

~~~
rijoja
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.

------
thetrumanshow
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.

~~~
jcoby
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.

~~~
lonnyk
>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?

~~~
jcoby
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.

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

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

~~~
brokenparser
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).

~~~
jcoby
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.

~~~
brokenparser
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.

~~~
jcoby
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.

~~~
brokenparser
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.

------
RossM
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...](http://files.zend.com/help/Zend-Server-Community-
Edition/content/optimizer_plus_component.htm)

~~~
Mahn
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.

~~~
cabirum
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.

~~~
nikic
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.

~~~
Mahn
That's great, thanks for sharing.

------
Mahn
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.

~~~
ecaron
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

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

~~~
lotsofcows
Bcrypt? It's all about scrypt these days.
[http://stackoverflow.com/questions/10149554/are-there-any-
ph...](http://stackoverflow.com/questions/10149554/are-there-any-php-
implementations-of-scrypt)

------
ch0wn
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>

