March 2014 on internals@php

Cet article est aussi disponible en français.

BTW, here’s the RSS feed of the posts I might write in English – oh, and if you know someone at planet-php and feel these posts have their place there, feel free to point them to this blog ;-).

This month of March 2014 has seen 611 mails on PHP’s internals@ mailing-list – which is a bit less than the month before which had more than 950 mails!

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

We can feel the feature-freeze of PHP 5.6 is getting close: not much related to RFCs has happened this month, and the rhythm of new discussions and ideas has slowed down compared to the previous months!

On March 7, PHP 5.6-alpha3 has been released. It should be the last alpha version for PHP 5.6, as a first bêta is planned for the end of the month¹.

This first bêta version will indicate the feature-freeze for PHP 5.6: no new feature or change shall be accepted for this version.

Following discussions started since a couple of months about a future major version of PHP, Julien Pauli posted a list of changes that could be made on the PHP engine itself.

Rasmus Lerdorf quickly noted this list was extremely ambitious (re-write of several components, including some difficult parts). That being said, as Pierre Joye answered, it should be possible to deal with at least some of these ideas.

Another factor that must be taken into account is that only a small portion of PHP contributors today have the knowledge required to work on these points – and not too many thing should be modified at the same time!

Still, where a minor version cannot break compatibility as seen be the language’s users, it doesn’t go the same way with internal behavior – which means these features and changes could come with PHP 6.1, 6.2, …

There have already been a few threads about Unicode, and Rowan Collins tried to summarize what Unicode support means.

He started with the fact that, today, a PHP string is nothing more than a stream of bytes – and this notion cannot disappear (for instance, it will remain useful to store binary data such as images). He then asked what the real needs are, when it come to text manipulation, for users – those needs not necessarily being tied to the internal representation of a string. Finally, he noted we have to think about an implementation that allows PHP to answer those needs.

Basically, most people seems to agree on the idea that strings should be represented, internally, as a Unicode charset. But let’s not forget that Unicode can actually correspond to four distinct encodings…

In the conversation, a question has been asked: should PHP accept identifiers (variable names, functions names, …) that are not ASCII? Considering the complexity that comes with Unicode, it seems for now the answer is no. Still, today with PHP 5.x, we are not limited to ASCII ;-).

Discussions will probably go on for a few month, before arriving to a solution that suits the needs: on this specific matter, the next PHP major version is expected by many!

Now that several PHP interpreters and compilers exist (HHVM from Facebook, KittenPHP form Vkontakte, the compiler to bytecode for the JVM JPJP, HippyVM when it comes to Python, …), each one of these tends to implement features that don’t exist in the original php.net’s engine, or to not implement some points that one does.

As a consequence, Ivan Enderlin noted the need for a PHP specification was getting real – and internals@ could work on the redaction of such a standard, as this mailing-list of developpers has some weight² on the language. This specification would be a logical next step after the RFCs began structuring the process of adding new features, those last years.

Johannes Schlüter answered that, as long as PHP is the reference implementation, every new feature must be implemented by this one to be considered as a part of the language. Of course, this answer goes against the idea of a specification, where the implementation that respects it should only arrives in second place.

On the other side, Andrea Faulds noted that a reference implementation is not a real specification, as a bug of that implementation can well be considered as a feature of the language. And it’s certainly something that happens, as the answer to “what should PHP do?” is often “what php-src does now”!

An idea might be to write this specification at the same time the next major version of PHP is developed. This way, the specification would reflect the reality of the implementation of PHP 6, and, at the same time, provide goals for other future implementations.

The discussion settled down at the end of the month. I’m curious to see how this proposal will evolve in the future, especially when development on PHP 6 will really begin!

Several long discussions have taken place in March about changes recently made to the sessions extension.

Andrey Andreev wrote the RFC: Sessions: Improve original RFC about lazy_write, which aims to improve the idea brought by RFC: Introduce session_start() options - read_only, unsafe_lock, lazy_write and lazy_destroy.

Julien Pauli noted the two new functions session_reset() and session_abort() that have been added recently did not raise an error when called with no initialized session – contrary to all other session-related functions. This should be fixed.

That being said, Andrey Andreev said a couple of times that these two functions were added a bit fast and did not bring much value – and, as such, he asked for them to not be added in PHP 5.6, to leave time for more thinking.

After a while, Julien Pauli insisted on the fact that PHP 5.6’s feature-freeze was getting close, and that deeper changes to the session extension could be made for the next major version of PHP.

After RFC: TLS Peer Verification passed, Chris Wright submitted a patch that enables peers verification for Windows without users having to set up any specific configuration. As it should help users a lot, it has been merged.

As Philip Sturgeon said after RFC: Array Of was rejected, a possibility for the future would be a support of Array of with a syntax close to Generics for PHP 5.7, followed by full support of Generics for PHP 6.

Combining the new power operator ** and the possibility of using expressions when defining constants, Tjerk Meesters proposed to merge to PHP 5.6 a Pull-Request that allows this kind of syntax:

const FOO = 2 ** 3 ** 2;

Last but not least, Jakub Zelenka announced a new JSON parser, under PHP license (this should solve problems that rose up a couple of months ago), which brings a nice performance and memory gain.

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.