Hi Marcio,
On Mon, Mar 2, 2015 at 3:07 PM, Marcio Almada <marcio.w...@gmail.com> wrote:
> 2015-03-02 1:43 GMT-03:00 Yasuo Ohgaki <yohg...@ohgaki.net>:
>
>> Hi Marcio,
>>
>> On Mon, Mar 2, 2015 at 8:02 AM, Marcio Almada <marcio.w...@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.
>
I understand your reasons. Compatibility is important, but detecting
function body contents and
suppressing errors by engine is too hacky. Raising E_DEPRECATE/E_STRICT by
function definition seems
the way to go. IMO.
[yohgaki@dev github-php-src]$ php -r 'function f(...$a) {var_dump($a);};
f(1,2,3);'
array(3) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
int(3)
}
[yohgaki@dev github-php-src]$ php -r 'function f($a) {var_dump($a);};
f(1,2,3);'
int(1)
is current behavior. The latter would be
[yohgaki@dev github-php-src]$ php -r 'function f($a) {var_dump($a);};
f(1,2,3);'
Deprecated: Excessive argument for f() without "...", called in Command
line code on line 1 and defined in Command line code on line 1
int(1)
User may have a lot of E_DEPRECATED errors anyway if strict scalar type
hint passes.
I like the idea. Please use function definition for errors. (E_DEPRECTED or
E_STRICT whichever
is suitable)
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
