Re: Re: [RFC] Named arguments

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