Re: [RFC][DISCUSSION] Strict Argument Count
| From: | Marcio Almada | Date: | Mon, 02 Mar 2015 06:07:14 +0000 |
| Subject: | Re: [RFC][DISCUSSION] Strict Argument Count | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-84144@lists.php.net to get a copy of this message | ||
Hi Yasuo,
2015-03-02 1:43 GMT-03:00 Yasuo Ohgaki <yohgaki@ohgaki.net>:
> Hi Marcio,
>
> On Mon, Mar 2, 2015 at 8:02 AM, Marcio Almada <marcio.web2@gmail.com>
> wrote:
>
> I like the idea.
>
> /** fn expects a variable-length argument lists */
> function fn($arg) {
> $arg = func_get_arg();
> $args = func_get_args();
> }
>
> fn(1); // Ok
> fn(...[1, 2, 3, 4, 5]); // Ok
> call_user_func_array("fn", [1, 2, 3, 4, 5, 6, 7]); // Ok
>
> I understand motivation why your patch behave like this. It's for BC,
> right?
>
Yes. If you search github for func_get_arg or func_get_args you wil get
around 2,734,673 results. That's a lot.
> However, isn't it better to declare variable length parameters by function
> signature
> in the long run?
>
> function fn($arg, ...) {}
>
> Is it possible to have E_DEPRECATED error without "..."? and do not care
> about func_get_arg*() existence? Make E_DEPRECATED error E_WARNING
> in PHP 7.2 or 7.3.
>
>
I'm not against doing this in a future when PHP v5.5 starts to fade away.
But, right now, a lot of code still needs to support PHP 5.5+ with no
alternative other than use func_get_args. Remember we only got the
dedicated syntax for variadic functions recently on PHP v5.6.
I'm afraid it's too soon to deprecate func_get_arg*s() or to overlook it.
Maybe in the future somebody will build upon this RFC, specially if it gets
approval, and start the deprecation. But at current pace I don't see this
as an alternative unless we all reach consensus, which is unlikely.
Another point is that internal functions are currently using warnings to
signalize wrong argument counts:
strlen <http://www.php.net/strlen>("foo",
"bar");
// PHP warning: strlen() expects exactly 1 parameter, 2 given on line 1
If the mailing list reach consensus that we should emit deprecation
instead, maybe internal functions will need to be updated too. I'm not
against it also, but I think it would be too soon for a lot of people here.
Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
Thanks,
Márcio