Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110843
User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668
Mime-Version: 1.0
Message-ID: <1ea0347c-b90a-4b0a-9a99-b4be19da8a0f@www.fastmail.com>
In-Reply-To: 
 <CAF+90c-=t2Wxr9f9dG-BSRw3=nWJPh4neT2LM05anf67-M-75Q@mail.gmail.com>
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>
Date: Sat, 04 Jul 2020 10:19:43 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Re: [RFC] Named arguments
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jul 3, 2020, at 9:35 AM, Nikita Popov wrote:

> 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.

That seems logical, although with the splat operator I don't know why anyone is using call_user_func_array() anymore to begin with.  Still, consistency is a good thing.

> Relatedly, I'm wondering if something like this should be allowed:
> 
>     call_user_func('strlen', str: 'foo');

Same statement: Seems logical, although why anyone is still using call_user_func() I don't know. :-)

--Larry Garfield