August 2014 on internals@php
September 10, 2014 —Cet article est aussi disponible en français.
I’ve been quite busy in August (and I’ve taken some holidays, during which I pretty much had no Internet access, which doesn’t help), and I haven’t been able to write my digest of internals@ for July 2014 in due time. Instead of writing it now and keeping getting late for August’s one, I’ve chosen to skip my digest of July – and to write August’s one, which you can read below.
August 2014 went back to a reasonable number of 700 messages on PHP’s internals@ mailing-list, after a busy month of July with 1144 mails.
As a graph representing the number of mails per month for the last three years, we’d get:
Johannes Schlüter started this month of August 2014 annoucing the first Release Candidate of PHP 5.3.29. Two weeks later, he announced the release of PHP 5.3.29, which marks the End Of Life of PHP 5.3 : no other new release of PHP 5.3 is planned (which means there won’t be any bug fix anymore – or even security fix).
As PHP 5.3 has reached its End Of Life, Jan Ehrhardt asked what would become of PHP 5.4. According to the Release Process, PHP 5.4, published in March 2012, should have gotten bug-fixes for two years. Still, like Stas Malyshev mentionned, it would be fair for PHP 5.4 to switch to “security fixes only” mode after PHP 5.6 is released – and maintaining two stable (5.4 and 5.5 – or 5.5 and 5.6) releases in parallel should be OK.
A few days later, Stas Malyshev announced that PHP 5.4.33 should be the last version of branch 5.4, except for possible security-fixes.
In the middle of the month, Ferenc Kovacs said the release of PHP 5.6 was getting close. And, a few days later, on August 28th, he announced the release of PHP 5.6.0!
In another thread, he explained why PHP 5.6 was two month late (according to the initial planning): several intermediate versions (alpha, beta, RC) have been released one or two week late, for different reasons – and, in the end, it adds up to two months.
Andrea Faulds noted it might be interesting to have one last 5.x version before the release of PHP 7 – which would mean PHP 5.7. The idea is that, as PHP 7 is a new major version, it will likely require about two years of work before it can be released – and it will include some new major features (and some BC-breaks).
A 5.7 release would facilitate the migration to PHP 7 – typically, by adding deprecation warnings for features that will greatly change. This intermediate version could also act as a fallback if PHP 7 was to be released later than expected. As Ferenc Kovacs pointed out, no minor release has, for now, been released in less than a year, and it seems hard to conceive that a major version (with more changes and more impact) could be released quicker.
Of course, as Derick Rethans, Zeev Suraski and several others answered, it might be better to put more energy into PHP 7, instead of dividing it between two versions. One should not reproduce what happened with PHP 6, where things stopped going forward because each developer wanted to add one more feature.
After the series of performances optimizations known as phpng had been developed on its separate branch for several months, Zeev Suraski opened the votes, at the beginning of the month, on RFC: Move the phpng branch into master, to decide if this branch would be merged to PHP’s master branch.
The matter had been debated a lot before and discussions were, this time, quite short – even if some indicated the changes brought by this branch were important and would have a strong impact.
In the end, this RFC passed, with 47 votes “yes” and 2 votes “no”. As a consequence, the phpng branch has been merged to master.
Andrea Faulds has written two RFCs related to functions and the Closure class:
The first one, which aimed to add a call() method to the Closure class, to allow binding at call-time, hasn’t been discussed much. Votes have been opened in the middle of the month and this RCS passed, with 13 votes “yes” et 0 votes “no”.
More messages have been exchanged about the second one: the idea was to add to PHP a syntax that would allow one to reference functions (in a more explicit way than just using their name as strings). As Stas Malyshev noticed, the proposed syntax might cause conflicts with passing parameters by reference, but the RFC seemed to be of interest for a few people.
Right at the end of July, Nikita Popov wrote the RFC: Abstract syntax tree, suggesting to add an intermediate step to the compilation process of PHP scripts.
This could allow new syntaxes that are currently impossible for technical reasons, might allow to remove a few hacks, and make the compilation of PHP scripts easier to maintain. By the way, the implementation that comes with the RFC already fixes a few syntax quircks (especially about yield and list). This change on the compilation process doesn’t have much impact on the execution of scripts: performances or memory usage will not change. Still, introducing an AST as some impact (10-15% gain for performances, at the cost of some increase in memory consumption) on the compilation phase.
Comment on this RFC have been quite positive and, without much surprise, it passed, with 47 votes “yes” and 0 votes “no”.
As a complement, it should be possible, in the future, to expose this AST to user-space (for static code-analysis, for example) and to provide extensions with some hooking mechanism so they could intervene during the compilation process.
Andrea Faulds wrote the RFC: Integer Semantics, which aims to improve cross-platform consistency for PHP integers by fixing a few cases for which behavior wasn’t clearly defined.
Kris Craig noted the role of a high-level language – such as PHP – should be to hide this kind of differences. Even if they made some sense when most developers were coming from a C-background, it’s less the case today.
Derick Rethans answered one must be extremely careful before breaking compatibility, including for a future major version like PHP 7. Any change that would be difficult to detect will create frustration for end-users and slow down the adoption of that new version. Several developers have confirmed this idea, pointing towards problems shown by Python 2 and 3 or Perl 6. Still, a major version definitely is the right time for improving the language.
Sara Golemon has written the RFC: Make defining multiple default cases in a switch a syntax error which wants to forbid using several default cases in a single switch block (today, only the last default is taken into account). Responses have been quite positives, to remove this odd behavior.
Some suggested a change of this type could have its place in PHP 5.7 – but it would go against the idea of not breaking compatibility between minor versions, which means this fix should find its place in PHP 7. Raising a E_DEPRECATED warning should be possible for PHP 5.7. After a while, Peter Cowburn asked if all this process (RFC, discussion on the mailing-list, votes) wasn’t a bit too much for something that could be considered as no more than a bug.
In parallel, votes had been opened, before some developers noticed the required minimum duration for discussions on a RFC, before opening it to votes, is two weeks. Considering those debates for something that felts like a bug-fix, Sara Golemon dropped the matter. Levi Morrison re-started it a few days later.
Note: the detection of this inconsistency is one of the first results of work started last month on the specification for PHP.
Marc Bennewitz wrote the RFC: Binary String Comparison, which states PHP’s behavior for comparisons is sometimes surprising when dealing with strings, as some type-casting is automatically used (basically, comparisons are non-strict) and proposes to change the behavior of non-strict comparisons for string so they become strict.
Several answers indicated changing this behavior today would cause problems, as it would break a major feature of PHP. In any case, considering some first responses, it doesn’t seem like this RFC is going to have much success.
Right at the beginning of the month, a mailing-list has been created for members of AFUP (French User-Group), to discuss in French about RFCs announced on internals@.
Following the discussions we’ve had on this mailing-list, I have (as I’m acting as its coordinator) posted a summary of AFUP’s members’ opinion on three threads:
- Our opinion about the
intdiv()RFC - Our thoughts about the merge of the
phpngbranch tomaster - And our opinion on RFC: Abstract syntax tree
Basically, we would like for the community (using a User-Group, to have some official entity) to participate more in the evolution process of PHP. This mailing-list and the resulting mails to internals@ seem to us like a good first step toward that goal.
Votes on RFC: intdiv() have ended: adding a new operator for integer division has been rejected (with 24 votes “no” and 5 votes “yes”) and the alternative solution – adding an intdiv() function – has passed (with 28 votes “yes” and 0 votes “no”).
To help with debugging, Dmitry Stogov suggested to add a new get_resources() function that would return a list of all existing resources (optionally limited to a specific type). This changes has been commited a few days later – no need for an RFC for such a simple thing.
Michael Wallner wrote the RFC: Add pecl_http to core. For now, only a few mails have been exchanged, but Johannes Schlüter noted it might be interesting to use this implementation for internal HTTP(s) stream – and for this extension to systematically (or, at least, by default) be enabled.
After several months of debates, Anatol Belski annouced the 64-bits patch for integers and strings length has (finally) been merged.
Dmitry Stogov set up a new memory manager for PHP 7. The matter has not been discussed much, but it seems this manager brings some performance gain – even it it might be relatively limited.
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.
