Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114417
User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416
Mime-Version: 1.0
Message-ID: <5650fab5-6006-4af2-b337-9e4aba67bf04@www.fastmail.com>
In-Reply-To: 
 <CAOWwgpmo-2ykSGQ-LjcScsvNw8=ZJf81pa0QQnMCj7XKZVxmpA@mail.gmail.com>
References: <f3d20496-c560-42b7-9a0d-8672b3cafa7d@www.fastmail.com>
 <df6d13a3-dfe6-44f4-a9eb-0fd065faf767@www.fastmail.com>
 <CAOWwgpmo-2ykSGQ-LjcScsvNw8=ZJf81pa0QQnMCj7XKZVxmpA@mail.gmail.com>
Date: Tue, 11 May 2021 12:55:12 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Partial function application
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, May 11, 2021, at 11:57 AM, Nicolas Grekas wrote:
> > On Sun, Apr 25, 2021, at 2:25 PM, Larry Garfield wrote:
> > > Greetings, Internalians!
> > >
> > > I would like to offer for your consideration another RFC, specifically
> > > syntax for partial function application.
> > >
> > > https://wiki.php.net/rfc/partial_function_application
> > >
> > > It includes an implementation by Joe Watkins that is already about 95%
> > > complete.  (There's some edge cases he's still sorting out, but all of
> > > the typical cases should work already.)  Most of the design work comes
> > > from Levi Morrison and Paul Crovella.  I helped out with the tests, a
> > > few edge bits, and general instigator/nudge. :-)
> > >
> > > Discuss.
> >
> > It looks like the conversation has died down, and it's been two weeks, so
> > pending any other notable feedback I'll open a vote on this RFC on Thursday
> > or Friday.
> >
> > --Larry Garfield
> >
> 
> LGTM, thanks for the RFC!
> 
> What about visibility? I suppose this works even outside the object scope?
> should this be mentionned?
> $foo = $this->somePrivateMethod(1, ?)

We're pretty sure it will work, and if you return $foo to another caller and then call it, it will work fine.  We'll add a test to confirm that.

> Would it make sense to support a way to use a placeholder for "all
> remaining args"?
> Eg:
> $foo = some_func(1, ...?)

That's already implicit in the way it works now.  If you placeholder at least one parameter, and then don't fill in all of the remaining parameters, any additional trailing parameters are always placeholdered.  So $obj->foo(?) will always return a partial that has the same arity as foo() does, regardless of how many parameters it has.

> Combined with my previous comment, this could replace
> Closure::fromCallable() by a language construct, which is something that we
> already discussed in another thread (we talked about some ::function
> special suffix instead):
> $foo = $this->somePrivateMethod(...?)

Yep.  That's noted in the RFC.  Although not the primary intent, a nice side effect is that any_func(?) is now a safe way to turn any function/method into a callable to reference it.  That renders ::function or similar 98% unnecessary.  (The remaining cases are mostly where you need to collect data statically for compilation or similar.)

> In this last form, we might make this result in Closure::fromCallable()
> exactly. Aka no increase of the depth of the stack trace.
> 
> BTW, ideally, partial functions should not increase the depth of the
> stacktrace at all. Do they?
> 
> Nicolas

They currently do, since they work by creating a Closure-esque object called Partial with an __invoke() method.  However, if you partial the same thing multiple times then only one stack level gets added.  That is:

function test($a, $b, $c, $d) { throw new Exception(); }

$first = test(?, ?, ?, ?);
$second = $first(1, ?);
$third = $second(2, ?);
$fourth = $third(3, ?);
$result = $fourth(4);

The stack at the end will contain only one partial "level", not 4.

--Larry Garfield