Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115183 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 9253 invoked from network); 28 Jun 2021 17:02:09 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Jun 2021 17:02:09 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id BA3CC1804D8 for ; Mon, 28 Jun 2021 10:21:56 -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=-0.4 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_H2,SPF_HELO_NONE,SPF_PASS,URIBL_SBL, URIBL_SBL_A autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (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 ; Mon, 28 Jun 2021 10:21:56 -0700 (PDT) Received: by mail-lf1-f49.google.com with SMTP id q16so19763214lfr.4 for ; Mon, 28 Jun 2021 10:21:56 -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=f5Mo3DJ8L6IglcUfvCEKVHmaJCCxYOga20AtXbV0fbI=; b=j//lGjQq14Q2DI9dYqd5hbYaCsHZqpiFFkVCAMYg5jDNXx4b+ZbRtwVfguvS83cdz3 M76BGp1QTc1AZAfPj09B3lMiEDu0J3DST4QmvHRuCXs1qaY4cBnNi3Km5tzzv+aTcWYz hHpUY9ULVi4UqINxIOMSZZS4U60N7TpDNINEWrCu+vF8WloqrjKryoJP4AozWyUpaG6o IKQhJ6PZj42KxwB99qs8z90k7P091ZaCJhi/baF1/6lpRi2HcaJNQVBXqszShsQH+73O o2L2F1p6rfWZPiVHXLQuXtoDe8Er0+lVuJbgpEJdfJQ1N3vgTE5NtHEKk7uavisAq7JH zTXg== 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=f5Mo3DJ8L6IglcUfvCEKVHmaJCCxYOga20AtXbV0fbI=; b=g/V/frOdi+f4pwtpKC3ZtjcxoHlEkI5+kOINCa7iQ6WgjuYHhmVw8QPKBNcraSIo2a KlMMbywAEf9Z7UBuTPx82iK3o8nH01SzvkEzxSJ0Qg6AGY4lTg8H3K7iCyw13PLtQpN/ ir5ytq60vmeV6r6gdIv2H4Cy99R2oYY5KYlZFzKyNgJDTKhEpmJK2rW9HgML3VPLC4C6 +BjBaecJE4kcpscw8sT5ZJD+worWF5B0+rvPgzAZexq3DgoBi3869YjBli0KdrOYJG9G wQ6AdrjgYtaJ1+BaQ8M+Ci6LpkY+AjTsZd4uxb6Q6HRCxZ6SPa/G5DinWhg8uArNA5YY HD+w== X-Gm-Message-State: AOAM533+t5BR7Dyr97ANN41ZH/c1WOtXYE5W50nlXmgZ1ROuy3W/RLU6 3ULc3obGLCypcOM8rgXZ8x7bUUTlfTRWkRtEwpM= X-Google-Smtp-Source: ABdhPJxUWVryWNqaWO48lm3pBSrT4nO4QmuUExE3n2afbuB+rjDVLhswuncBCz3ieUpVRZNZCKnVf970m/5NvaNZDNE= X-Received: by 2002:a05:6512:39ce:: with SMTP id k14mr5695302lfu.418.1624900913613; Mon, 28 Jun 2021 10:21:53 -0700 (PDT) MIME-Version: 1.0 References: <222b3921-3d9b-47f9-8d13-e6a123f36fad@www.fastmail.com> <919141bc-9b59-48f4-929f-6f0434dd7317@www.fastmail.com> In-Reply-To: Date: Mon, 28 Jun 2021 19:21:41 +0200 Message-ID: To: Levi Morrison Cc: Larry Garfield , php internals Content-Type: multipart/alternative; boundary="000000000000c04fad05c5d6b980" Subject: Re: [PHP-DEV] [Vote] Partial Function Application From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=) --000000000000c04fad05c5d6b980 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 28 Jun 2021, 18:49 Levi Morrison, wrote: > On Mon, Jun 28, 2021 at 10:32 AM Olle H=C3=A4rstedt > wrote: > > > > On Thu, 24 Jun 2021, 18:02 Larry Garfield, > wrote: > > > > > On Wed, Jun 16, 2021, at 11:16 AM, Larry Garfield wrote: > > > > Hi folks. The vote for the Partial Function Application RFC is now > > > > open, and will run until 30 June. > > > > > > > > https://wiki.php.net/rfc/partial_function_application > > > > > > > > Of particular note, a few people had asked about using ...? instead > of > > > > ... for the variadic placeholder. In the end we decided not to > explore > > > > that, as Nikita explained off-list it was actually more confusing, > not > > > > less, as it would suggest "placeholder for a variadic" rather than = "a > > > > placeholder that is variadic." Otherwise, it's just more typing. > The > > > > syntax choices section of the RFC has been updated accordingly. > > > > > > Since some people still don't grok the use cases, I've written a blog > post > > > to make the case for them better than a detail-oriented RFC can. > > > > > > > https://peakd.com/hive-168588/@crell/the-case-for-partials-and-pipes-in-p= hp > > > > > > There has also been some positive Twitter chatter, as well as the > level of > > > +1s on that post (which is, I think, the highest of any PHP post I've > had > > > on there, ever), so I think the demand for it is definitely there in > the > > > ecosystem. It's just not people who frequent Internals. :-/ > > > > > > I'd say there are definitely people that want to use partials. > > > > > > --Larry Garfield > > > > > > -- > > > PHP Internals - PHP Runtime Development Mailing List > > > To unsubscribe, visit: https://www.php.net/unsub.php > > > > > > Out of curiosity, what would it take to implement function aliasing in > PHP? > > To enable a limited form of pipes, like `foo |> bar`. > > > > Olle > > We probably could special case it for pipes; it's more of a matter if > we _should_. But, to do it generally so that things like > `array_map(strlen, $arr)` work is not trivial. The main issue is that > different symbol types have separate "tables", if you will. The engine > decides to look in one bucket or another based on the syntax. In this > case, based on syntax the engine will look in the constant table for > `strlen`, as `strlen` in `array_map(strlen, $arr)` is a constant > lookup by syntax. > > If we want it to fall-back to looking in other tables, then we'd have > to deal with various challenges: > 1. We have to deal with symbol collisions that exist today somehow, > such as if `strlen` exists both as a function and a constant, or if > `$this->count` exists as both a property and a method. I would prefer > to do the simple thing and forbid collisions, but there are other > strategies. > 2. How do we handle the fact that different symbol types behave > differently in namespaces when the symbol doesn't exist? > 3. Also, how do we handle differences in case sensitivity between symbol > types? > > Personally, I think it's worth it to change all of these things, > because it could also give us function and constant autoloading. Of > course, we'd have to get 2/3 of voters to agree on solutions to these > things, which probably includes some backward-compatibility breaks so > that might be difficult. But, nobody has tried so maybe not. > Right. So you'd have to add a resolve sympol type routine, and if it returns "this is a function/method", strlen would evaluate to be wrapped in a lambda? Then the problem would be the overall performance cost of such a routine, and to deal with collisions, as you said. Hm. Well, couldn't another alternative be that pipe operator assumes a callable it can wrap on its right side? This wouldn't allow the array map use case, but it would allow others. A third alternative would be to type-cast to callable, perhaps. array_map((callable) strlen, $arr); This would be a shorter version of manually writing out the wrapping lambda. But there's already fn, so. No big benefit. Olle --000000000000c04fad05c5d6b980--