Hi Marcio,
On Thu, Mar 5, 2015 at 4:07 AM, Marcio Almada <marcio.w...@gmail.com> wrote:
> 2015-03-03 16:48 GMT-03:00 Yasuo Ohgaki <yohg...@ohgaki.net>:
>
>> Hi Marcio,
>>
>>
> 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.
>>
>>
> Just one correction, we are not "suppressing" the warning. It just emits
> the warning conditionally and that's not hacky at all. We already have
> other situations where warnings are emitted just when certain conditions
> are met.
>
>
>> [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)
>>
>>
> Using only the function signatures, overlooking *func_get_args()*, would
> be in practice an indirect deprecation of* func_get_args()* and that's
> not negotiable at all, at least on this RFC.
>
> We simply can't do this now because it would be an enormous BC break and
> PHP 5.5, which has no "first class" variadics, is still supported. I
> understand the reasons you want to do it, but I think we should wait a bit
> more before discussing a possible *func_get_args* deprecation (if it will
> ever be deprecated). That's not the point addresses by this RFC.
>
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);
?>
array(3) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
int(3)
}
"...$a" packs arguments. Using "..." as variable parameter indication may
be allowed.
Strictly speaking, it's not needed, though.
>
>
>> User may have a lot of E_DEPRECATED errors anyway if strict scalar type
>> hint passes.
>>
>
> That's highly speculative. We don't even know if the proposal of scalar
> typehints with BC breaks will ever get voted, neither if it will pass. It's
> not a good idea to take decisions based upon that. Don't you think so?
>
It's related, but it's different issue.
>
>
>> 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.
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.
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?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
