Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69095
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <522BB60F.8030903@nebm.ist.utl.pt>
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>
	<522BB60F.8030903@nebm.ist.utl.pt>
Date: Thu, 12 Sep 2013 15:05:31 +0200
Message-ID: <CAF+90c_ff_dMK1qhr_fc7boJC7spVMyZDowicKRigkK7mUKjsQ@mail.gmail.com>
To: Gustavo Lopes <glopes@nebm.ist.utl.pt>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0149c5068d5f4c04e62f6493
Subject: Re: [PHP-DEV] [RFC] Named parameters
From: nikita.ppv@gmail.com (Nikita Popov)

--089e0149c5068d5f4c04e62f6493
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Sep 8, 2013 at 1:26 AM, Gustavo Lopes <glopes@nebm.ist.utl.pt>wrote:

> 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 think you mentioned yourself why support for unknown named params (in the
following "kwargs") is necessary: Call forwarding. If you want to do a
forwarded call with named params you need some kind of kwargs support.

I don't see how we can support call-forwarding with named params for
existing code (without breaking BC in cufa), but we should at least be able
to implement it in new code. The ...$params syntax allows this. E.g. here's
a simple example where __invoke is forwarded to another method:

    /* OLD: No named params support */
    public function __invoke() {
        call_user_func_array([$this, 'someMethod'], func_get_args());
    }

    /* NEW: With named params support */
    public function __invoke(...$params) {
        $this->someMethod(...$params);
    }

This works easily for __invoke (not sure if it works right now, but easy
enough to support), but not so well with __call and __callStatic. E.g. if
you have something like this currently:

    /* Forward unknown method calls to the method name with prefix _
     * (to support method names that are keywords) */
    public function __call($method, $args) {
        call_user_func_array([$this, '_' . $method], $args);
    }

You can not directly translate that to code supporting named args, because
this makes use of an $args array rather than variadic arguments.

I'm wondering whether it's okay to add the unknown named params to $args
here. For old code this will work. If new code tries to use named params
with old code this would also run, but not have the correct result (no
error that is).

Alternative I could allow __call declarations with __call($method,
...$args) and only in that case collect named args.

Not sure about any of this, didn't really consider the forwarding issue
previously.

Nikita

--089e0149c5068d5f4c04e62f6493--