Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115168
MIME-Version: 1.0
References: <1ae611cb-b077-3db0-3237-c7ffa1c6e745@ralphschindler.com>
In-Reply-To: <1ae611cb-b077-3db0-3237-c7ffa1c6e745@ralphschindler.com>
Date: Mon, 28 Jun 2021 11:28:03 +0200
Message-ID: <CAF+90c_fPx1VNcyB1xUS4n1jH6hHHQm0XQ8u+je=VUST_k6LrQ@mail.gmail.com>
To: Ralph Schindler <ralph@ralphschindler.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000024206405c5d01cda"
Subject: Re: [PHP-DEV] [Proposal] call_user_func_map(): flexible named
 parameter mapping for call_user_func*
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000024206405c5d01cda
Content-Type: text/plain; charset="UTF-8"

On Sun, Jun 27, 2021 at 4:39 PM Ralph Schindler <ralph@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

--00000000000024206405c5d01cda--