December 2013 on internals@php

Cet article est aussi disponible en français.

I’ve been doing a monthly digest of what happens on internals@ for more than a year now, each time in French. Every now and then, some people said it would be nice to have it in English too… So, here’s my first shot at this!

2013 ended with 489 messages in December, which is just a little bit more than the month before [fr].

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

Ferenc Kovacs, RM of PHP 5.6, announced a release timetable for this future version. If things go as planned, the steps leading to the release of PHP 5.6 should be:

• 1st alpha version in January 2014 (no more new RFC proposal from this point on),
• 1st beta version in March 2014 (feature-freeze),
• 1st RC version in May 2014,
• and release of the first stable version, PHP 5.6.0, in the middle of June 2014.

For now, the features corresponding to the following RFC have been merged:

• Importing namespaced functions
• Constant Scalar Expressions (with constants)
• Internal operator overloading and GMP improvements
• Remove calls from incompatible context
• Dedicated syntax for variadic functions
• Crypt() function salt
• phpdbg

This list of RFC represents the biggest changes currently planned for PHP 5.6. There could also be some smaller changes here and there, and we still have a few months before feature-freeze ;-)

It’s one of the threads with the greatest number of mails this month¹: Nikita Popov announced he had opened votes on the RFC: Exceptions in the engine – the idea of which being to replace as many fatal errors as possible by exceptions, in PHP itself.

For the curious ones: this mail lists some of the errors that cannot be converted to exceptions, and some of those that can easily be.

From the beginning, Nikita fixed the following rule:

If you are in favor of the proposal in general, but want to have it in PHP 6 rather than PHP 5.6, then vote “No” here.
If it fails now, someone can revive this once the time for PHP 6 has come.

Integrating this modification to PHP 5.6 has been declined, with 24 votes “for” and 21 votes “against” (this was a modification impacting the language; which means it needed 2/3 “yes” to pass).

Still, considering that more than half the votes were “in favor” and the discussions that took place lately about this idea, I have no doubt it will come back when we are talking about PHP 6 – maybe it was just a little bit too much of a change to be part of a minor version.

We can feel that PHP 5.6 is getting near, with several RFC going through the voting process one after the other:

Votes have been opened on the RFC: phpdbg at the beginning of the month. With 40 votes “for” and 0 votes “against”, it passed: phpdbg will be bundled with PHP 5.6!

The RFC: Slim POST data has too been opened to votes. With 17 votes “for” and 0 votes “against”, it passed for PHP 5.6.

Daniel Lowrey announced votes were opened on the RFC: TLS Peer Verification. With 25 votes “for” and 0 votes “against”, this one passed too: by default, PHP 5.6 should include this verification, providing better security.

The RFC: Power Operator, about which I wrote about last month [fr] has too been opened to votes – before they got reset following an update of the RFC. More or less in parallel, many discussions have still taken place, especially about the associativity and the precedence of this new operator. The voting period ends at the beginning of January 2014, but things seem to be going well for now.

Nikita Popov opened the votes on the RFC: Argument Unpacking. Here too, things seem to be going quite well for an integration to PHP 5.6, and final results will come in a few days.

Rouven Weßling wrote the RFC: Timing attack safe string comparison function, the idea behind it being to ease the fight against timing attacks.

This proposal received some interest, even if the first suggested name did not convince, something like strcmp_secure() possibly being better suited – or not.

A part of the discussion was about the fact that such a function can already be implemented in PHP… But an implementation bundled with PHP might anwer a common need, and highlight the fact that string comparisons, to be secure, require a few precautions. Actually, this was part of the idea behind the addition of password_hash() to PHP 5.5.

Andrea Faulds noted its is possible to increment a string with the ++ operator, but that we cannot use -- for the inverse manipulation. As a consequence, he suggested this second behavior could be implemented.

A question that has quickly been asked is how "a" should be decremented: "0" ? or "-1" as in Perl?
Another idea would be to decrement "a" to an empty string, which could itself be re-incremented to "a". But it would not be compatible with the current behavior.

Following this discussion, Andrea Faulds has created the RFC: Alphanumeric Decrement.

Yasuo Ohgaki posted that a 0 GMP object is not considered as being empty(). He also noted that is_scalar() returns false for a GMP object – same thing for is_numeric(), btw.

The idea behind those notes was that GMP objects will work a bit like numbers with PHP >= 5.6 (because of the mechanism provided by PHP 5.6 to allow operator overloading for classes declared by extensions), and those points could be surprising for end-users.

Following those posts, Yasuo Ohgaki announced he had began working on the RFC: GMP number.

A few months ago, an optimization for some cases caused a performance-regression for strtr() in several other cases. This month, Zeev Suraski noted it might be a good idea to cancel that modification (which shouldn’t have been deployed, considering its impact): as it sometimes takes months to win a few percents on performances, it’s a bit sad having introduced this regression and only taking care of it six months later.

Still, as noted by Pierre Joye, going one step forward / one step backward is not a real solution, especially considering this modification only impacted the performance of a single function.

Actually, as suggested by Hannes Magnusson, this kind of optimization (which caused, here, a regression in some cases) maybe shouldn’t be done in a minor version…

Ondřej Hošek wrote the RFC: ldap_modify_batch. There have not been many comments on that matter – which is often a good sign (or, it shows the ldap extension is not used much).

Sara Golemon noticed base-conversions done by PHP are sometimes a bit surprising, and wrote the RFC: Fix base_convert() and related PHP lib functions in which she proposed a couple of ideas of solutions.

Stefan Neufeind talked about his idea of a new function called get_class_constants(), based on the model of get_class_methods() and get_class_vars(). Some have answered that, as the Reflection already provides a way to access these informations, it is probably not necessary to add a new dedicated function to PHP.

Following a discussion started in october, Yasuo Ohgaki wrote about the RFC: Use default_charset As Default Character Encoding, and it has been opened to votes.

Anatol Belski did a report on the progress of enhancements for 64 bits platforms – work that’s been going on for a few months.

Yasuo Ohgaki wrote the RFC: Introduce session.lock, session.lazy_write and session.lazy_destory – but his propositions didn’t cause much discussion for now; maybe some end of year effect?

And, to finish this digest, Lior Kaplan has kept on posting his reports about pull-requests for PHP: on December 5 and on December 20

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.