Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68959
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.21 cause and error)
Message-ID: <522BB60F.8030903@nebm.ist.utl.pt>
Date: Sun, 08 Sep 2013 01:26:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20100101 Thunderbird/22.0
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>
CC: PHP internals <internals@lists.php.net>
References: <CAF+90c85v_VTPTPanBcTJ70Ff6pm6fRgAGs4n1uoaA+B9UZg=w@mail.gmail.com>	<522A47BC.30100@nebm.ist.utl.pt> <CAF+90c_Qz9afwZTdMuYpGRtfX+xww=cYMsXP9Nt=UUTPrH-oDA@mail.gmail.com>
In-Reply-To: <CAF+90c_Qz9afwZTdMuYpGRtfX+xww=cYMsXP9Nt=UUTPrH-oDA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Named parameters
From: glopes@nebm.ist.utl.pt (Gustavo Lopes)

On 06-09-2013 23:54, Nikita Popov wrote:
> On Fri, Sep 6, 2013 at 11:23 PM, Gustavo Lopes <glopes@nebm.ist.utl.pt>wrote:
>>
>> I think the correct course of action is just to drop support for extra
>> named arguments. Just add an extra array argument to the function and you
>> have equivalent functionality without having to go through these edge cases.
>>
>
> Dunno, personally I don't have a strong need for the extra named args.
> That's something Stas considered important (in the discussing re skipparams
> RFC). Would be interesting to know for what they are currently used in
> Python/etc and whether those use cases are sufficiently important to us.
>

The advantages would have to be very significant in order to justify 
breaking all the call forwarding code out there relying on 
call_user_func() and func_get_args().

It also unnecessary complicates the variadics calls for the callee that 
now receives a potentially non-numeric array. The caller may have 
slightly better syntax, but there being no information on support of 
extra named parameters on the signature is an extra complication. And at 
this point I haven't seen any convincing argument as to how this is more 
than marginally better than an extra array argument for the caller and 
any better at all for the callee.

>
>> I also disagree about your idea about how to handle changed parameter
>> names. Having an E_ERROR here is absolutely unacceptable. This would be a
>> major BC break (not to mention inconsistent with the other other signature
>> mismatches are handled).
>
>
> Yes, I certainly do not want to throw any fatal-ish error here. Maybe I
> didn't make that clear in the RFC. (What do you mean with "inconsistent
> with the other other signature mismatches are handled" though? For
> signature mismatches involving interfaces we currently use fatal error.
> Signature mismatches between classes are E_STRICT.)
>
I meant the E_STRICT on rather more worrying situations like:

class A { function a(array $a) {} }
class B extends A { function a(SplArray $a) {} }

>> In fact, I think ANY message here would waste millions of $currency in man
>> hours. I can't think of any easy solution there. An alternative solution
>> would be to keep a flag on whether argument names changed and refuse to
>> accept named arguments in the case a call is made to an instance whose
>> class or some its parents changed parameter names, but this comes with some
>> memory penalty.
>>
>
> Eh, I don't know. Getting an error at the call-site is already too late.
> You'll get one anyway because the parameter name doesn't exist. Unless
> mismatching parameter names are exceedingly common, I'd think a lowly
> E_STRICT level error would be bearable.
>

Too late for what? If there is a mismatch but named arguments are not 
used, there is no problem with the code (if you don't consider named 
parameters not being permitted a problem). In any case, a more specific 
error is better than a generic one.

That said, I'm on the fence here because it's not really nice to have 
named parameters being permitted in a call to method A::b() but having 
the same call forbidden to B::b(), where B extends A.

Regards

-- 
Gustavo Lopes