Hi,

2015-03-04 21:51 GMT-03:00 Yasuo Ohgaki <yohg...@ohgaki.net>:

>
> I don't think we need to deprecate func_get_args().  We may have
>
> <?php
> function f($a, ...) {
>   var_dump(func_get_args());
> }
>
> f(1,2,3);
> ?>
>
> "...$a" packs arguments. Using "..." as variable parameter indication may
> be allowed.
> Strictly speaking, it's not needed, though.
>
>

I think you are missing a "detail" here. Even if we add "..." to the
language, people on PHP 5.5 would not be able to have it because this new
syntax would be available only on PHP 7.0+ . We still have to account for
func_get_args otherwise people maintaining packages for both PHP 7 and 5.5
will have no alternative to fix the warning. Do you get me?


>
>>
>> I like the idea. Please use function definition for errors. (E_DEPRECTED
>>> or E_STRICT whichever
>>> is suitable)
>>>
>>>
>> I'm proposing a warning because currently PHP internal functions already
>> use a warning to indicate wrong argument count. Using E_STRICT or whichever
>> would look inconsistent IMMO at a first sight. But I think that E_STRICT ||
>> E_WARNING || E_DEPRECATED is a very debatable topic
>>
>
> I don't care much about error types, because I change code so that any
> errors are not raised anyway.
> E_WARNING in this case makes sense because users made obvious errors.
>
>
Great, so warning seems ok and it's good to keep consistency with other
already well established language behaviors.


> I understand you would like to address errors in older code with compiler
> change. We don't have to
> care much for older broken code. IMO. I understand importance of argument
> count check. Your
>  wordpress research clearly shows that we must raise error for wrong
> number of arguments.
>
>

It's not "old broken code", it's PHP 5.5+ code and I already told you that
this would be a bad BC break because:

1. people still have to support PHP 5.5, emit a warning ignoring
func_get_args will only cause pain and won't these people.
2. this would impede the RFC to pass because we would now have a major BC
break instead of a minor helpful one, and the RFC was proposed to help
people, you saw the uses cases on the RFC.


> Looking into function body and checking certain function existence seems
> just too much for a
> language. However, I don't have too strong opinion for this. I would like
> to have comments from engine
> developers. Any thoughts?
>

It would be nothing new or weird. It's just a simple compile time check. We
already "inspect" code in many other situations while compiling and a lot
of behaviors during execution already depend on compile time checks. I
don't think this is "too much". It might sound unusual, at first, but there
is nothing wrong with this.


> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
>

Reply via email to