2015-03-10 12:31 GMT-03:00 Patrick ALLAERT <patrickalla...@php.net>:
> Hello,
>
> Le lun. 2 mars 2015 à 00:03, Marcio Almada <marcio.w...@gmail.com> a
> écrit :
>
>
> I'm globally +0.5, however I have some concerns:
>
> What about constructors?
>
> Children classes may have a bigger number of arguments for their ctors
> than their parents. Even if not very elegant, it is possible some are
> passing a fixed number of arguments while constructing an object, whether
> that object will take it into account or not.
>
> Something like:
>
> class A {
> function __construct($a)
> }
>
> class B extends A {
> function __construct($a, $b)
> }
>
> $kind = $bool ? "A" : "B";
>
> $object = new $kind($foo, $bar);
>
I think this is somehow covered here
https://wiki.php.net/rfc/strict_argcount#hassle_factor, the example is not
explicit to ctors but the same principles seem to apply. Not sure you have
a deeper point on it though as PHP is a weirdo and allows constructors on
interfaces.
Also, FYI, before we reach discussion phase, there was an idea to ignore
ctors and other magic methods but you are the first person to bring it up
on the ML. I'm not very inclined to ignore any other magic methods other
than *__call* and *__callStatic* for now.
>
> Why aren't you using E_NOTICE?
>
> [1]: Run-time notices. Indicate that the script encountered something that
> could indicate an error, but could also happen in the normal course of
> running a script.
>
>
I have nothing against E_NOTICE in this case and indeed E_NOTICE seems like
a good fit. I'll add it as an option.
> E_DEPRECATED:
> -1, what is E_DEPRECATED is supposed to be removed in a future version.
> And that is a huge BC break if it happens. Btw, you're not mentioning in
> which version of PHP the support of extra parameters would be removed.
>
>
I was sympathetic towards E_DEPRECATED in the early stage of discussion
phase but I'm not anymore. If somebody would like to E_DEPRECATE something
related to argument count in the future, the this person will have to
create another RFC and start the deprecation on PHP 7.1. I'm removing this
option now :)
> E_WARNING:
> -1, IMHO, calling functions/methods with more arguments generally has less
> impact than other aspects that currently generate E_NOTICES (e.g. using
> undefined variables, constants,...). Using an error reporting level
> stronger than for those cases looks inconsistent.
>
>
I disagree with the "looks inconsistent" part. The E_WARNING option would
actually be the most consistent with current PHP behavior. Ex:
function fn($a, $b){}
fn(1);
PHP warning: Missing argument 2 for fn(), called in...
If we choose E_WARNING both minimum and maximum argument count will have
the same error level. BTW, in some cases an exceeding argument can be even
more dangerous than a missing argument.
I have no strong feelings regarding to the error level, the E_WARNING vs
E_NOTICE seems legit so I'm waiting for more opinions.
Cheers and thanks for the impressive work so far!
>
> Patrick
>
> [1] http://php.net/manual/en/errorfunc.constants.php
>
You're welcome. Thanks for the useful feedback. Hope we can reach a
consensus on the options before the voting starts.
Márcio.
