Den 2016-06-13 kl. 15:07, skrev Rowan Collins:
On 06/06/2016 08:22, Dmitry Stogov wrote:
Hi,
This mini RFC has been moved to "Voting" state. Voting
began on Jun 6 and will close on June 16.
You can find the full RFC at: https://wiki.php.net/rfc/too_few_args
Hi,
The more I think about this RFC, the less I agree with it being
included in 7.1.
I realise this is now officially late in the approval process to raise
these points, but note that the discussion period was just 5 days,
when a language change would normally require 2 weeks.
On the one hand, it doesn't stop a function's author from having to
check for missing data, as claimed.
As far as the receiving function is concerned, there is no difference
between a missing parameter and an explicit null; both are currently
allowed by default, and both are prohibited if a (non-nullable) type
hint is present. Any unhinted parameter can accept nulls, so a
defensive programmer must always check for them.
Like strict_types mode, the change only actually affects the *caller*
of the function. We can posit two types of user: those who read and
fix all warnings, and those who ignore them. To a user who reads all
warnings, this change makes no difference: they were already avoiding
this behaviour by fixing the warnings. To a user who doesn't, it is a
breaking change, which may prevent their application from running on
PHP 7.1.
On the other hand, there is a real risk of people delaying adoption of
7.1 because of these new errors.
On the face of it, it seems like it would be trivial to fix code not
to trigger this error, but there are more complex cases, such as
callbacks. A simple example:
function foo($a, $b, $mode) { }
$callback = 'foo';
$data = [1,2];
usort($data, $callback);
This code will run under all current versions of PHP, but throw an
Error under 7.1 if this RFC passes. If the definition of foo(), the
origin of $callback, and the usort line, are all in different places,
it may not be trivial to determine the correct fix for this.
There is an assumption from those who have spoken in favour of the RFC
that such warnings will rarely be ignored in real world code, and
therefore nobody will actually be affected by this. Here, we are
pitching anecdote against anecdote; my feeling is that many people
routinely ignore warnings, and will consider their code to be "running
fine" under 7.0, then see it "crash" under 7.1.
I was pleased when the "minor versions will retain BC" policy was
adopted, because I thought it would avoid the problems we had with PHP
5.3 and 5.4, and allow wider adoption of the latest version. Allowing
this change would mean that promise has been broken.
Regards,
I would like to add another perspective given that we have a large
migration project going from PHP 5.x to 7.x this autumn. I have a
hunch that we are not alone in that situation.
So for us it makes perfectly sense to have this kind of feature / bug
fix as early as possible. Since it capture an erroneous behaviour, it
helps raising the quality of our code which I see as a clear benefit!
And pardon me, but saying that we can wait until an PHP 8.0 release
that we have no clue about when it will happen sounds in my eyes
a bit to far off. Going that direction means instead that boiler plate
code is needed to catch that exact number of parameters is sent.
So I wonder are we here making a hen out of a feather? But of course
if the release process needs clarifying then do it, but please keep the
feature as is.
Regards //Björn Larsson
PS I could add that if this kind of change had come very late in the 7.x
release cycle I might have been of another opinion.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
