Re: [RFC] Replace "Missing argument" warning with "Too few arguments" exception
| From: | Fleshgrinder | Date: | Wed, 01 Jun 2016 17:30:27 +0000 |
| Subject: | Re: [RFC] Replace "Missing argument" warning with "Too few arguments" exception | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-93682@lists.php.net to get a copy of this message | ||
On 6/1/2016 1:33 PM, Rowan Collins wrote:
> I like the concept behind this, but I worry it might have a rather large
> BC impact. Like removing call-time pass-by-reference, there may be a lot
> of long-untouched code that needs fixing to work within this constraint.
> I'm not even sure how easy it would be for static analysis to identify
> these cases. I guess on the flip-side, people will *probably* have
> Warnings displayed or logged already...
>
> The RFC would also benefit from more discussion of the current behaviour
> in different cases:
>
> function foo($a) {}
> foo(); // Warning
>
> function bar(A $a) {}
> bar(); // Error
>
> function baz(A $a=null) {}
> baz(); // OK
>
> function quux(?A $a) {}
> quux(); // Not sure. Error?
>
> function wibble(int $a) {}
> wibble(); // Error (regardless of strict_types, I think)
>
> function wobble(?int $a) {}
> wobble(); // Error?
>
> Any other cases?
>
> Certainly, making these consistent would be nice, but like a lot of
> consistency, does it come at too high a price?
>
I fully agree with Rowan here. First we need a proper plan for all these
cases and a consistent behavior. Next we need to discuss if something
like this can be introduced in a feature release or requires a major
release.
Note that func_get_args() should die too since we have variadic
arguments now. However, this can only be introduced in a major version.
(Correct me if I am wrong and didn't thought of a very common use case
that requires func_get_args(). I for one never need it.)
Whether references need to die completely or not is a more complicated
discussion. There are valid use cases for them. However, they should be
avoided and other solutions should be preferred if possible.
--
Richard "Fleshgrinder" Fussenegger
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc