On Sun, Jun 27, 2021 at 4:39 PM Ralph Schindler <ra...@ralphschindler.com>
wrote:
> The short proposal:
>
>
> Make a variation of this work (notice parameter order and 'b' is goes
> unused):
>
> call_user_func_map(
> fn ($c, $a) => var_dump($a, $c),
> [
> 'a' => 'the a value',
> 'b' => 'the b value',
> 'c' => 'the c value'
> ]
> );
>
> // string(11) "the a value"
> // string(11) "the c value"
>
>
>
>
> The long proposal:
>
>
> Callables, Closures, Anon Funcs, etc - have enjoyed increasing
> popularity year over year. We've even gotten a shorter syntax for them
> `fn ()` and more RFC's are sure to be on their way.
>
> This proposes a method for a publisher/framework/producer (the caller of
> the callback) to document all the parameters that are available as named
> parameters, and subscribers/consumers (creator of the callback) could
> subscribe to what they need by name.
>
> For example:
>
> // documented callback parameters, this is what is available:
> $params = [
> 'a' => 'value for a',
> 'b' => 'value for b',
> 'c' => 'value for c'
> ];
>
> // a consumer only interested in $a and $c could write:
> $f = fn ($c, $a) => var_dump($a, $c);
>
> The consumer would then register their callback with the
> producer/framework/etc or pass as the parameter to whatever is consuming it
>
> $callbackSystem->register('some_event', $f)
>
> // or
>
> $doSomething->with($f);
>
> The framework could then call with success:
>
> call_user_func_map($usersCallable, $allAvailableNamedParameters);
>
>
> Currently the only way to do this is through array_diffing parameters
> found via Reflection, then passing them along to call_user_func_array()
> as a named array.
>
> Attempting to use call_user_func_array() without specifying all provided
> variables results in:
>
> Uncaught Error: Unknown named parameter X in ...
>
> Thoughts?
>
Just to make sure I got this right: call_user_func_map() is the same as
call_user_func_array(), but a) only accepts named params and b) silently
ignores unknown named params?
I'm not really convinced by your use-case here. This seems like a rather
odd way to design an API, which goes against commonplace assumptions. If
you pass a closure somewhere, the general expectation is that the parameter
names you use are irrelevant and only the order matters. This creates a
very unusual API contract, and while I can't prevent you from doing that,
I'm pretty sure this is not something we want to endorse with additional
library support.
What's wrong with good old fn($params) => $params['a'] + $params['b']? (The
same question for named parameters in general is answered by
https://wiki.php.net/rfc/named_params#what_are_the_benefits_of_named_arguments
-- notably none of the arguments made there are relevant in this context,
the only benefit I see is saving a few keystrokes.)
Regards,
Nikita
