Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110847
MIME-Version: 1.0
References: <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
 <CAF+90c_hndba0oLbL-BX9i3N-1Dhy=R2xW-hq6C0Rv2j3mKcTQ@mail.gmail.com>
 <CAF+90c8jwAk4RnGCVMC=e-L_OnvYYjnK69gUiKgGEMe26WDZdA@mail.gmail.com> <CAF+90c-=t2Wxr9f9dG-BSRw3=nWJPh4neT2LM05anf67-M-75Q@mail.gmail.com>
In-Reply-To: <CAF+90c-=t2Wxr9f9dG-BSRw3=nWJPh4neT2LM05anf67-M-75Q@mail.gmail.com>
Date: Mon, 6 Jul 2020 17:03:57 +0200
Message-ID: <CAF+90c_B-W_qnmt8GrQ6h+Wsb8yN9skzqPVwdFSXrvmC3FNVow@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000e942305a9c730c3"
Subject: Re: [RFC] Named arguments
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000000e942305a9c730c3
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 3, 2020 at 4:35 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Mon, Jun 29, 2020 at 5:13 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> On Tue, Jun 23, 2020 at 12:10 PM Nikita Popov <nikita.ppv@gmail.com>
>> wrote:
>>
>>> On Tue, May 5, 2020 at 3:51 PM Nikita Popov <nikita.ppv@gmail.com>
>>> wrote:
>>>
>>>> Hi internals,
>>>>
>>>> I've recently started a thread on resurrecting the named arguments
>>>> proposal (https://externals.io/message/109549), as this has come up
>>>> tangentially in some recent discussions around attributes and around object
>>>> ergonomics.
>>>>
>>>> I've now updated the old proposal on this topic, and moved it back
>>>> under discussion: https://wiki.php.net/rfc/named_params
>>>>
>>>> Relative to the last time I've proposed this around PHP 5.6 times, I
>>>> think we're technically in a much better spot now when it comes to the
>>>> support for internal functions, thanks to the stubs work.
>>>>
>>>> I think the recent acceptance of the attributes proposal also makes
>>>> this a good time to bring it up again, as phpdoc annotations have
>>>> historically had support for named arguments, and this will make migration
>>>> to the language-provided attributes smoother.
>>>>
>>>> Regards,
>>>> Nikita
>>>>
>>>
>>> As we're moving in on feature freeze, I plan to move this proposal
>>> forward soonishly.
>>>
>>> I have update the RFC to drop the syntax as an open question (I haven't
>>> seen much opposition to the use of ":"), and to describe the possible
>>> alternative LSP behavior at
>>> https://wiki.php.net/rfc/named_params#parameter_name_changes_during_inheritance
>>> .
>>>
>>> While writing this down and implementing it, I found that this has more
>>> odd edge-cases than anticipated. Overall, I'm not sold that this approach
>>> is worth it. It sounds nice on paper, but I strongly suspect that it solves
>>> a problem that does not existing in practice, and will force us to keep
>>> this patch-over mechanism indefinitely, while the real solution would have
>>> been to fix the limited amount of code that is in the intersection of
>>> "renames parameters" and "is actually invoked with named arguments".
>>>
>>
>> Just as another reminder: I plan to put this to voting by the end of the
>> week.
>>
>> I've also updated the RFC to make the LSP behavior a secondary vote. I'm
>> not convinced this is a good idea myself, but some others seemed to prefer
>> this approach.
>>
>
> I've made two additional changes to the proposal:
>
> 1. Explicitly mentioned attribute support in
> https://wiki.php.net/rfc/named_params#attributes1, and added it to the
> implementation (oops). ReflectionAttribute::getArguments() will also return
> named arguments to the attribute, and ReflectionAttribute::newInstance()
> will behave in the intuitive manner.
>
> 2. Added some information on internal APIs in
> https://wiki.php.net/rfc/named_params#internal_apis. The tl;dr is that
> named params are pretty much completely transparent for normal extensions,
> but there are some additional APIs if for example you want to perform a
> named param call from an extension.
>
>
> In relation to this, I'm also considering to change the semantics of
> call_user_func_array() to treat array elements with string keys as named
> parameters, rather than simply ignoring keys. The motivation here is not so
> much call_user_func_array() in particular, but various other APIs that do
> the same thing, such as ReflectionMethod::invokeArgs(), which should all
> behave consistently.
>
> Relatedly, I'm wondering if something like this should be allowed:
>
>     call_user_func('strlen', str: 'foo');
>
> I'm leaning towards "yes", in which case call_user_func_array() should be
> also be treated consistently.
>

Okay, I think I've now done the last set of updates to this RFC:

 * call_user_func(), call_user_func_array(),
ReflectionClass::newInstance(), ..., now support named parameters.
 * I've moved the alternative LSP behavior into the alternatives section
and don't plan to pursue it in this RFC. After thinking it over, I think
this is a nice migration hack, but not something that should be part of the
language long term.

Regards,
Nikita

--0000000000000e942305a9c730c3--