June 2014 on internals@php

Cet article est aussi disponible en français.

Before really talking about internals@: some of you have come see me during the PHPTour (a 2-days event organized in France by the AFUP – it took place this year on June 23rd and 24th in Lyon) to speak about this series of posts I’ve been writing for about a year and a half (about 6 months in English), thank me and encourage me, telling me this allows you to keep track of what’s going on around PHP’s development. Thanks!

June 2014 came back down to a reasonable 493 messages on PHP’s internals@ mailing-list, after a month of May with more than 800 mails, including some long discussions about phpng.

As a graph representing the number of mails per month for the last three years, we’d get (the full history since 1998 is available here):

The release of PHP 5.6 keeps getting closer: on June 6th, Ferenc Kovacs announced beta 4, which should be the last version before the RC phase.

Indeed, two weeks later, PHP 5.6’s firt Release Candidate has been published!

According to RFC: Define PHP 5.3 end of life, the End Of Life of PHP 5.3 is fixed to one year after the release of PHP 5.5 – which took place on June 20th, 2013.

As the last bugfix release of PHP 5.3 has been published six months ago, Stas Malyshev said a last release would be published soon (probably in July), to fix a few remaining bugs.

Ferenc Kovacs noted it would be useful to insist on the fact there will not be any additional future release of PHP 5.3 – and it’s more than about time for people to switch to more recent versions!

Pierre Joye posted about a new tool which is currently being developed, to install PHP extensions: RFC: Pickle.

The mid/long term idea is to remove the pecl PEAR command, and for composer to be able to work with this new pickle tool to install extensions.

Right at the beginning of the month, Andrea Faulds wrote an RFC nammed “Bare Name Array”, which would bring two new syntaxes, a bit shorter than those we use today (like [] is shorter than array()), to work with arrays in PHP.

The first one would allow us to write arrays this way, without changing the current behavior of =>:

$tableau = [
    clef1: "valeur 1",
    clef2: 42,
    clef3: [
        sub1: 25,
        sub2: "aaa",
    ],
];

Later during this conversation, Adam Harvey asked if going farther was possible, setting up something like Ruby’s symbols – which would not be easy in PHP, especially when it comes to syntax.

The second idea would allow us to access array elements this way:

echo $tableau:>clef3:>sub2;

As these two proposals are quite distinct, Levi Morrison noted they should be split in two separate RFCs – and Andrea Faulds quickly created them: RFC: Bare Name Array Literal and RFC: Bare Name Array Dereference.

Votes on these RFCs have been opened after a few additional mails – and they both have been rejected (the first one with 14 “no” votes and 3 “yes” votes, and the second one with 15 “no” votes and no “yes” vote).

Basically, it seems those changes of syntax were not necessary and made the language more complex – having two syntaxes with distinct behaviors was not intuitive.

Last month (in May), a change related to serialization made its way to PHP 5.4.29 and 5.5.13. It caused a break in components such as Doctrine or PHPUnit, on a specific case sometimes used to create objects without the class’ constructor being invoked, (which is kind of a hack, especially when used on internal classes).

Both projects have quickly been updated, but Jakub Zelenka noted it would be interesting to quickly release a fix at PHP’s level itself, both for developers or other projects that might be suffering from the same problem.

As Benjamin Eberlei then said, if PHP was tested on a couple of projects and libraries (and not only on PHP’s tests themselves) before each release, this kind of regression could have been avoided¹. That being said, as Johannes Schlüter answered, it would be helpful if developers using PHP were testing RC versions and posting feedback a bit more – which is not always easy and could be made easier if nightly versions of PHP were available on Travis CI.

The discussion about the solution that should be implemented mig/long-term lasted a bit of time – during which Travis CI switched to the last version of PHP, causing failures in PHPUnit tests on several projects. Still, Ferenc Kovacs insisted on the fact that pushing a fix too rapidly was not necessarily the best thing to do.

In the end, a basic solution has been implemented for PHP 5.4 and 5.5 in order to fix projects that were suffering from this break. A more complete solution will then be implemented for PHP 5.6.

Nikita Popov wrote the RFC: Uniform Variable Syntax, which aims to get a more consitent and complete syntax for variables, for PHP 6².

Even if the discussion hasn’t been long, the feedback has been quite positive. It has even been suggested some checks could be added in PHP 5.7 to facilitate detection of points that will likely break in the future.

Pierre Joye reminded us the security that corresponds to the open_basedir directive can be obtained by setting up permissions at the system level, be it with Windows or Linux – which means the effort required to maintain that directive might not be that useful. As a consequence, he suggested it could be removed for PHP 6.

Julien Pauli quickly answered it was indeed not needed anymore, it was easy to circumvent, and that removing it would allow for some cleaning up in several portions of PHP’s source code.

Still, even if open_basedir doesn’t bring a real level of security, this feature mitigates the risk for some kind of bugs to be exploited and facilitates their detection. Actually, provided developers use PHP’s streams properly and don’t think open_basedir is related to security, keeping this directive could be interesting.

The RFC: Fix handling of custom session handler return values passed for PHP 5.7, with 10 “yes” votes and zero “no” vote.

At the end of the month, Timm Friebe annouced votes were opened on RFC: Catchable “call to a member function of a non-object”. If this RFC passes, calling a method on something that’s not an object (like NULL, for examples) will trigger a E_RECOVERABLE_ERROR instead of a Fatal Error.

Andrea Faulds wrote the RFC: Big Integer Support, which aims to keep working with integers even for very large values, where PHP now falls back to floats when values don’t fit in the range integers can represent. The first answers have been rather positive, even if some points still need clarifications before the RFC can go forward in the next weeks.

David Zuelke posted a fix that will allow php-fpm to work better with Apache.

Finally, after an RFC about anonymous classes has been rejected some time ago, Sebastian Bergmann re-started discussions on this idea, with a case in which he thinks they could be useful (for tests). I’m curious to see if, this time, the idea will go farther – maybe PHP 6 could help with that?

internals@lists.php.net is the mailing-list of the developers of PHP; it is used to discuss the next evolutions of the language and to talk about enhancement suggestions or bug reports.
This mailing-list is public and anyone can subscribe from the page Mailing Lists, or read its archives using HTTP from php.internals or through the news server news://news.php.net/php.internals.