Cet article est aussi disponible en français.
809 messages have been exchanged in October 2014 on PHP's
internals@ mailing-list – a bit more than in September.
As a graph representing the number of mails per month for the last three years, we'd get:
|Month||Number of mails|
First of all, PHP 5.6 has entered its normal cycle of releases, with a first maintenance version at the beginning of the month.
Nikita Popov has written the RFC: Remove deprecated functionality in PHP 7, suggesting to remove from PHP 7 everything that was flagged as deprecated on all 5.x versions including, for example :
ext/mysql, affectation of
new by reference, functions to manipulate
# comments in
php.ini, … Considering the impact the removal of the first two points might have, this RFC might get voted in three steps (one vote for each of the first two points, and a third one for the remaining ideas).
Kris Craig noted that
ext/mysql has been obsolete for a while – and the fact some sites and tutorials are still referencing it should not prevent its removal. Also, Rasmus Lerdorf said most PHP users get their installations and PHP extensions from their distributions and those tend to package PECL extensions as if they were provided directly with PHP.
Johannes Schlüter insisted that, independently of the eventual removal of
ext/mysql, educating users is important, to ensure they stop using this extension – and Derick Rethans added that
ext/mysql having a procedural interface is not a good enough reason in itself to justify its removal. Zeev Suraski also reminded us that every time a feature is broken of removed, updating becomes a bit harder for users.
On the other hand, as Pierre Joye answered, if deprecated features never get removed, there is no use in flagging them as deprecated and one could just stop doing that.
In the middle of the month, Zeev Suraski announced the RFC: PHP 7.0 timeline, which aims to quickly release PHP 7 (in about one year), even if it means not getting some features. Things that break compatibility should make it for PHP 7.0 (as BC-breaks are only possible for major versions), but other features that don't cause BC-breaks could arrive with PHP 7.1 or 7.2. Waiting for too long might also lead to a version with too many incompatibilities, which would slow its adoption down.
Xinchen Hui answered indicating he thought one year was a bit long. Others quickly noted it might be better to not go too fast : several ideas could yet be taken into account for PHP 7 – even if only compatibility-breaking stuff must go into the 7.0 version (still, one should not forget anything, to avoid having to wait for another ten years).
Rasmus Lerdorf also indicated the
master branch might require a bit of time to get stabilized – even more on a project with its fair share of legacy code, like PHP, where each change can have consequences that are not always very well anticipated.
Variadic functions having been added to PHP 5.6, Marco Pivetta proposed to flag as deprecated, for PHP 5.7, functions
func_get_arg – in order to remove them later, for PHP 7. They could, if necessary, be re-implemented in user-space, for the compatibility of applications using them.
Andrea Faulds answered this removal would cause a great BC-break for applications, which would no longer work with a basic install of PHP 7 – even if it is possible to re-implement them in user-space. Removing those functions would also not bring any real gain.
After a new XML remote-debugging protocol has been implemented for phpdbg, Pierre Joye noted it could be interesting to check whether it is possible to get closer to the DBGp protocol already used by Xdebug. Joe Watkins explained the implementation of that new protocol took place following discussions with PhpStorm's developers. Bob Weinand then listed a few differences between those two – which could maybe have been added to DBGp?
Stas Malyshev also said that working outside the PHP project for several weeks before merging an entire feature might not be the best way to go for a component that's integrated in PHP: more discussions could have taken place if those developments had been done in a feature branch of PHP's repository (well, it has not necessarily been the case in the past – but it goes the same way for PHP as a whole, where changes are not reviewed much). That being said, it would be great if work done here could lead to a unified debugging protocol for PHP.
David Soria Parra then indicated going with an RFC could have been profitable, to think about setting up a new protocol and the best suited solution. Julien Pauli added having a separate website for phpdbg was odd (it's not usual for components of PHP) and its content could be moved to php.net (it seems to be planned). As phpdbg is a part of PHP, it should follow PHP's processes.
A few days later and following suggestions in the previous thread, Ferenc Kovacs explained RMs of PHP 5.6 had decided to revert changes brought to phpdbg and not published yet (remote debugging support): as this component is a part of PHP, its major evolutions might require a stabilisation phase and they should follow the process in place for PHP's evolutions – mostly, going through RFCs. Those changes have been reverted a few hours later, and will come back in the future.
Andrea Faulds wrote the RFC: Big Integer Support, proposing to set up, at an internal level, two kind of integers: traditional integers (limited to numbers that can fit on 32 or 64 bits) and integers based on GMP, which would allow to manipulate numbers as large as one wants. These two internal types would be exposed to user-space as a single integer type, with no size-limit.
Stas Malyshev answered adding a new internal type would require all extensions to take it into account – which means many of those would have to be updated.
Regarding some license issues with GMP, the RFC has been updated later. A benchmark has also been published to show this proposal doesn't have any real impact on PHP performances, even if more in-depth tests should be done.
After about two weeks, discussions on this matter have stopped, without any decision being reached. We'll see in the next few months if this RFC comes back to the front of the stage.
Joe Watkins wrote the RFC: UString, which introduces a new
UString class, that would provide features related to Unicode strings manipulations. Basically, this
UString class would, in a way, take the place of the existing
mbstring extension, which is not perfect, with an implementation based on ICU (already used by
Intl), faster than
Dmitry Stogov noted that, if this RFC doesn't include using
UString objects from the engine or other extension, it is incomplete and doesn't answer all needs (for example, Unicode strings couldn't be used as keys of arrays, as they would be objects and not real strings – unless another idea gets accepted). Of course, as Johannes Schlüter indicated, a better approach would be a real adoption of Unicode, but PHP 6 showed this is not that easy.
In the previous thread, Stas Malyshev announced he had begun working on RFC: Objects as hash keys, which proposes to add a new magic method (like
__toKey()) that would allow us to use objects as array keys.
Joe Watkins suggested
__toScalar() could be an appropriated name, closer to what this method would actually do, without limiting one to the currently discussed context – but this name would not explain the usefulness of this method.
Etienne Kneuss noted this RFC doesn't actually mean using objects as array keys (it would require a lot of work on re-writing PHP HashTables’ handling), but only simplifies syntax. As such,
array_keys() would not return objects, but only their hashes, as calculated by this new method.
Andrea Faulds wrote the RFC: Readonly Properties, based on the fact it is now hard to define a property that can be read from the outside of a class, while not making it writable in the process: one has to write getters/setters and/or play with
__set (in any case, we have to write code and its not really efficient). To solve this, the RFC proposes to add a new
readonly keyword, that could be used on class properties, to indicate which ones should be readable from the outside of that class.
Rowan Collins noted it would make user-space objects closer to those exported by some extensions (which can have read-only properties) – and it would indeed be great not to have to write numerous lines of code to get this feature. Others suggested to add more precise access-rules, with a syntax like
var $callback as rwxrw---x;.
Still, as Jordi Boggiano indicated, another possibility would be to talk again about RFC: Property Accessors Syntax, which was going farther while allowing what's proposed here – which only answers a portion of the different needs. Nikita Popov also noted the
readonly keyword is not necessarily explicit and, contrary to getter methods, properties can't be defined in an interface. Maybe one could already reserve the syntax for accessors, while only implementing a small part for now?
In the end, Andrea Faulds removed this RFC, as it was a bit confusing and only answered a portion of what was needed.
Andrea Faulds noted this two variables are poorly named:
$_GET corresponds to parameters received from the query-string, while
$_POST contains data from the request's body – another way of seeing things is they correspond to form methods, and not to HTTP primitives. Still, switching to variables like
$_REQUEST could have some sense, but would completely destroy compatibility. On the other hand, Rasmus Lerdorf indicated users know how to use
$_POST and adding aliases might be going a bit far: of all that might be confusing in PHP, this specific point would be near the bottom he the list.
The discussion has been intense, with almost one hundred mails in a few days, but I don't feel like it lead to a decision. In any case,
$_POST are here to stay – but we might see some other aliases appear in the future…
Florian Margaine answered PHP should focus on providing implementations more than interfaces: up to user-space to decide how the code should look like. Removing the super-globals (
$_POST, …) would also break pretty much all existing applications and adoption of PHP 7 would greatly suffer – even if they are not the most perfect interface that could be.
Larry Garfield also indicated there were discussions around that matter on the FIG's mailing-list and user-space is probably more appropriate for this kind of experimentations.
Andrea Faulds wrote the RFC: Safe Casting Functions, because the existing explicit transtyping operators never fail and never raise any kind of error – which can be dangerous (especially if used on user-supplied data), as they can return pretty much anything if used on garbage-data.
This RFC aims to add three functions, that would validate their input instead of blindly transtype it:
to_int(): would only accept integers, floats containing integer values that can fit in integers, or strings containing a textual representation of integers.
to_float(): would only accept floats, integers and strings representing floats.
to_string(): would only accept strings, integers, floats and objects that can be transtyped to strings.
The question of the return-value of these functions has quickly been asked (typically, is
false a value?), as well as the idea of having them throw exceptions – which could depend on an optional parameter.
Stas Malyshev noted some validation rules already exist in the
ext/filter extension and completing them could be more interesting that adding yet another set of rules somewhere else. Using names such as
to_int() could cause some confusion for users, as the behavior would not be the same as
(int) and a name like
lossless_int() might be more appropriate.
Discussions where not finished at the end of the month, and I'm guessing they will go one next month ;-)
Nikita Popov re-launched the RFC: Exceptions in the engine, which was originally targeting 5.6 – not all errors will be turned into exceptions, but a majority of them could be. As before, answers have been rather positive.
Thomas Gossmann asked whether it is possible to remove the
function keyword from methods declarations. Levi Morrison quickly indicated this idea had been rejected before, mostly because it would make searching for definitions and code reading harder – while not bringing much to the table. He is not the only one who thinks that.
Votes have begun on RFC: loop + or control structure. With 4 “yes” and 11 “no” votes, it didn't pass – Leigh, author of this RFC, explained why he, himself, voted “no”. We'll see if someone else brings back this idea in the future.
Changes corresponding to the RFC: Catchable “call to a member function of a non-object”, which passed this summer, have been merged.
Davey Shafik reported an
E_DERECATED warning is always raised, with PHP 5.6, if
always_populate_raw_post_data is set to something else than
-1 – and the default value is
0. It is yet the best possible compromise, with a default configuration value that doesn't break compatibility, but also warns users this is a feature that will be removed in the future.
Stas Malyshev brought the RFC: Filtered
unserialize() back on the stage. It aims to change the
unserialize() function, so we can forbid objects unserialization, or limit them to a set of listed classes.
In the middle of the month, Levi Morrison indicated he has a working implementation for RFC: Return Type Declarations and a few changes had been made to the RFC. Which means it's likely votes will begin on this RFC soon.
email@example.com 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