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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
