Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84262
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.50 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAOsHV+td_i5Z3JPmPF5WT8gAvhPFReO28L3TGPaYWgybSVnbSA@mail.gmail.com>
References: <CAOsHV+uApxF=pQngonMppam2AEnW0Sm1ESAaB9exLH0K0hMBWA@mail.gmail.com>
 <CAGa2bXYx-MGjhHVkDRYsHSRR4b+x4ba5PVxdhw9W2B1z0fWCEQ@mail.gmail.com> <CAOsHV+td_i5Z3JPmPF5WT8gAvhPFReO28L3TGPaYWgybSVnbSA@mail.gmail.com>
Date: Wed, 4 Mar 2015 04:48:47 +0900
Message-ID: <CAGa2bXbgDcjXWgoDw_X61KDbeiV_tcHpGk5RFSFsnQ1-LSNVPw@mail.gmail.com>
To: marcio3w@gmail.com
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c03a7eecc7d8051067a163
Subject: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c03a7eecc7d8051067a163
Content-Type: text/plain; charset=UTF-8

Hi Marcio,

On Mon, Mar 2, 2015 at 3:07 PM, Marcio Almada <marcio.web2@gmail.com> wrote:

> 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.
>

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
yohgaki@ohgaki.net

--001a11c03a7eecc7d8051067a163--