April 2014 on internals@php

Cet article est aussi disponible en français.

This month of April 2014 has seen 355 messages on PHP’s internals@ mailing-list – which means it’s been a calm month, with about only half the number of mails of March.

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 decrease in the number of mails, already started last month, is confirmed: PHP 5.6 is in full beta-stage – which means that no new feature can be added anymore. As a consequence, discussions have settled down a bit, and have not really begun about the next version yet.

On April 10th, Ferenc Kovacs announced that PHP 5.6.0beta1 had been tagged – and it’s been released the day after!

This transition to beta stage marks the feature-freeze of PHP 5.6: new features cannot be added to this version anymore.

In parallel to PHP 5.6 entering beta stage, Julien Pauli created a list of points on which he thinks the majority of developers agree, for the next major version of PHP:

• a new major release of PHP should be published; as soon as possible,
• it should be named “PHP 6”,
• when necessary, backward compatibility can be broken, and this version can introduce new concepts,
• the main concept to concentrate on for now is Unicode,
• ideas talked about up until now have been regrouped on https://wiki.php.net/ideas/php6,
• and development should be done in a two-years iteration.

The following steps would be:

• to begin writing RFCs targetting PHP 6 and discuss the corresponding ideas,
• and to create the PHP 6 Git branch.

Kris Craig noted switching to a more organized git workflow than what’s currently done would be interesting. His mail has been followed by a discussion about what’s being done now, as well as on the role of Release Managers when it comes to features and their merge.

Another idea, as suggested by Nikita Popov, would be to use the master branch to play this role of next major version, and to only create the new version branch when the release gets closer.

At the same time, Johannes Schlüter wrote that it might be interesting to merge release branches to their parents – but the idea didn’t seem convincing.

Eli later came back on the question of what number should be used for this future version, telling about results of conversations he had several times with members of the community.

In his opinion, PHP.next should not be called “PHP 6”: too many resources exist about “PHP 6” as it was thought of five years ago – and keeping this version number would cause a lot of confusion (there are books – dead leaves ones – about “PHP 6”, for example! And there are many articles on the matter, as well as slides of presentations given here and there, …). We should not forget that a vast majority of developers using PHP are not part of the community and don’t always keep track of what happens on the front lines.

Going straight to “PHP 7” might be an acceptable solution to this “problem”, and should not really give a bad image: “PHP 6”, today, would already be considered as a failed experiment.

Of course, not everybody agrees with this proposal. After all, “PHP 6” has never been released and stopped when it still was a development branch! In addition, communication covering the release of the next major PHP version should quickly cover and hide most of the stuff we can yet find about the old PHP 6.

Still, as Trevor Suarez noted, we should maybe begin by coding this future version; its name might be decided later, when the release gets closer ^^

Stas Malyshev tried to get some attention on the fact that PHP tests on Travis CI never stay green for long – to the point the normal state is for tests to fail.

A first step to fix this would to accept as a goal, for the PHP developers team, that tests must stay green. Then, sending a mail to the one who broke the build might help (the PHP tests suite is long – and developers don’t always re-launch it on their computers before each commit).

Following the thought and trying to formalize it a bit, Stas Malyshev wrote the RFC: Keeping PHPT Tests Green. Ferenc Kovacs added it could be interesting to use a wider configuration for Travis in order to test more things (more extensions, several PHP build configurations, …). Of course, ideally, all changes should be done on branches, and tests should be green before those get merged.

Votes were not finished at the end of April, but things did seem to go in the right way, with a large majority of “yes”. The answer seems less obvious when it comes to deciding what should be done when tests fail – the decision might not get written in stone, and could be taken by the RMs on a case by case basis.

Levi Morrison announced the RFC: Return Type Declarations, which would allow developers, when writing the declaration of a function or a method, to indicate what type of data it must return. For example:

function foo(): array {
    return [];
}

It’s not the first time such an idea is discussed – and the RFC shows in what way this proposal is different from the previous ones.

The first posts have been quite positive, especially as the RFC has a well defined perimeter and answers a need that’s been expressed many times in the past. In addition, this proposal would also be helpful for the PHP-FIG, as type-hinting would become possible for both return and parameters types on interfaces it defines.

As PHP 5.6 has reached its feature-freeze, this RFC targets PHP 5.7 or PHP 6. I’m curious to seen how things will evolve – but, considering the first discussions, they seem to be going the right way!

Leigh asked what other developers thought about the idea of accepting negative offsets for positions in strings, to extract characters from their end; for example:

$string = 'foobar';
print $string[-1]; // prints 'r';
print $string[-2]; // prints 'a';

The first comments seemed quite positive, even if using the same syntax for arrays and strings can cause some confusion for users.

Of course, this proposal might be more interesting if it was possible to specify an interval, and not just the offset of a character:

"foobarbazbuz"[4:7] => "barbazb"
"foobarbazbuz"[4-7] => "barb"
"foobarbazbuz"[4,7] => ["b", "b"] 

In the end, going a bit further, we would arrive to what Python accepts ;-). That idea doesn’t seem to be good for everyone.

Last month, Jakub Zelenka has begun working pecl/jsond, a new JSON parser implementation for PHP. There are still many tests to write and PHP 5.6 is now feature-frozen, so this new parser might arrive with PHP 5.7.

Timm Friebe wrote the RFC: Catchable “call to a member function of a non-object”, which aims to raise non-fatal E_RECOVERABLE_ERROR errors when one tries to call a method on something else than an object – like NULL, typically.

Rowan Collins started a thread on error handling and exceptions: re-thinking those could have some benefits (and a new major version would indeed be a good opportunity). The discussion has mostly revolved around the @ operator; and the fact that PHP errors today cover several use-cases.

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.