Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119681
MIME-Version: 1.0
References: <CAM0CcxhpMr_SstLCgcMfESTo4_H6yAPuBZb6B08KjbnKS97VfA@mail.gmail.com>
 <abdad88b-f6c3-433c-a56e-ad7a23257408@app.fastmail.com>
In-Reply-To: <abdad88b-f6c3-433c-a56e-ad7a23257408@app.fastmail.com>
Date: Fri, 10 Mar 2023 22:16:57 +0200
Message-ID: <CAM0Ccxir2792FgiQHVr2wP8WEbWTN2nT6NkY+wxVmXKkKEBpSg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e8234405f69171fd"
Subject: Re: [PHP-DEV] First-class callable partial application
From: zsidelnik@gmail.com (Eugene Sidelnyk)

--000000000000e8234405f69171fd
Content-Type: text/plain; charset="UTF-8"

I glanced over this RFC and suggested syntax has question marks. Each one
stands for a single parameter.

Since there are named arguments already, it seems to be redundant. We'd
rather pass couple of named arguments and place the ... construction at the
ending than twirl around with question marks in order to describe which
parameters final closure will have.

When we do PFA, what we think of is what we pass, not what would be
necessary to pass afterwards.

And yes, any feature should start from the smallest possible form. If we
try to implement all at once, we would get nowhere.

On Fri, Mar 10, 2023, 9:53 PM Larry Garfield <larry@garfieldtech.com> wrote:

> On Fri, Mar 10, 2023, at 1:04 PM, Eugene Sidelnyk wrote:
> > Hello internals!
> > I'm just wondering why First class callable syntax doesn't allow partial
> > application?
> > Recently I stumbled across following scenario where it could be really
> > useful:
> >
> > ```
> >     public function __invoke(SendOtpCommand $command)
> >     {
> >         $this->cache->get($command->getPhone(), $this->storeOtp($command,
> > ...));
> >     }
> >
> >     private function storeOtp(SendOtpCommand $command, ItemInterface
> $item)
> >     {
> >         // some logic
> >     }
> > ```
> >
> > In this example, I supposed that the closure created will accept a single
> > parameter $item, and when it is called back, method storeOtp will accept
> > both $command and $item. As it turned out to be, it doesn't really work
> > this way.
> >
> > Another simplified example:
> >
> > ```
> > // partial application
> > foo(bar(1, ...));
> >
> > function foo(Closure $closure)
> > {
> >     $closure(2);
> > }
> >
> > function bar(int $a, int $b)
> > {
> >     var_dump($a, $b); // 1, 2
> > }
> > ```
> >
> > Closure in foo accepts only one parameter. But when it is actually
> > dispatched, bar is called with two arguments.
> >
> > Are there any pitfalls, which prevent implementation of this nifty
> feature?
>
> There actually was an RFC for full partial application a few years ago:
>
> https://wiki.php.net/rfc/partial_function_application
>
> The main drawback is that in order to work, it had to do some very tricksy
> things with very critical parts of the code (how functions get called).
> Enough people felt that was too risky for the functionality and it didn't
> pass.  First-class-callables were deliberately submitted (
> https://wiki.php.net/rfc/first_class_callable_syntax) as a sort of
> "junior version" of partial function application that could be done with
> far less invasive changes.
>
> I'd *love* to see some form of PFA make a come-back, either with a simpler
> implementation or a reduced scope that allows for a simpler
> implementation.  I am not aware of anyone actively working on it at the
> moment, though.  (If anyone is, please speak up!)
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--000000000000e8234405f69171fd--