Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114419 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 12970 invoked from network); 11 May 2021 18:24:50 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 11 May 2021 18:24:50 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 899991804DA for ; Tue, 11 May 2021 11:32:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 11 May 2021 11:32:38 -0700 (PDT) Received: by mail-ej1-f45.google.com with SMTP id u21so31152713ejo.13 for ; Tue, 11 May 2021 11:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vvKUzrqArX//JrnVLEHqr1sIxnC6pwFiYZ5cP/HbjHQ=; b=iuy5nfllbl7M+Qp90ilKW3vDlhSGTPt/TUBpm774AiaufChjnsLyhlhMuw/zYUesEi svaeuV9GvZCqymG5SqKsojCIZvdnDalglkV8FAxGEk6TUXp5Jf/8SXOGpSoZU4x7kWku G+Lk8ov6i6bJ3VfHipO7hUlD2HzKSL2G9S1crMJOuRZEED/QvdHq/FpGiJBWX4u4aDHB WDNtBgPN6ow9G2UeEl8Q8yd5ShkW7lkkR82RlPskouQqfCh9TY1h5ouf/BXY5O6NvTZL Al5zM7392fpN1coy9ImJsA8LwHwEYIxVx8W8F6EzRsmDgSIfrNkjWEQll90BD6QkOVjt daqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vvKUzrqArX//JrnVLEHqr1sIxnC6pwFiYZ5cP/HbjHQ=; b=llLjlxSWpy3a6IbktesNkcjJCRa/NLFGLx6ie23MwjpL+UE6TOiNhkqTOWzuNg/vXX f4+C2hSI9sUMFQoIHEZO8DbMK2uyae18aVuopk2pv5hDyxG7s7xq+ai27SjLX7PdfkT5 h62s+bqw2q3nY2NN53RCRpfidBfPLV+QED5OfdcUKKGTpxGoJooy/ydrgDHp5HU3WshV rizNifo9AMhK+uMhiWDB8/OSHnIE+mKGxMmBIBTRIEQASey9Y2N4YXXXTL0AFVpaYoXp vjwP+fmHAdnlU0CpmZVN5GZUde6dArR1l02ZYgIti7HBPYm0r9vz701DyS5DUbRb/qyn MSlQ== X-Gm-Message-State: AOAM533hUZKcSmjWumIRpaxR09AmRUvxIQcfms5xQBbAhopqWzJtqjAS 5tOgy9DnQsXcOqvXWqVht+vU8R3hc6OOjB5rAFbwwPC+BxQ= X-Google-Smtp-Source: ABdhPJxmVaZFcbhnyWXIr+ND4otsUdrDEVL6a+M0IYjpPhiQIL2asgmkpQn9ZRbljxhyr45FDGHbTN5NBcMDBo/fI9g= X-Received: by 2002:a17:906:4c82:: with SMTP id q2mr33176601eju.80.1620757956627; Tue, 11 May 2021 11:32:36 -0700 (PDT) MIME-Version: 1.0 References: <5650fab5-6006-4af2-b337-9e4aba67bf04@www.fastmail.com> In-Reply-To: <5650fab5-6006-4af2-b337-9e4aba67bf04@www.fastmail.com> Date: Tue, 11 May 2021 20:32:24 +0200 Message-ID: To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="00000000000045907e05c2121e5b" Subject: Re: [PHP-DEV] [RFC] Partial function application From: nicolas.grekas+php@gmail.com (Nicolas Grekas) --00000000000045907e05c2121e5b Content-Type: text/plain; charset="UTF-8" > > > 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.) > Great news! > 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. > Nice. Would it be possible to optimize this and remove the extra frame? At least maybe for the (?) case? This makes me wonder: can we create a partial programmatically? Wouldn't that be needed for some use cases? Partial::createFromCallable($callable, the-args)? Nicolas --00000000000045907e05c2121e5b--