Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115182 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 6255 invoked from network); 28 Jun 2021 16:29:21 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Jun 2021 16:29:21 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 32A3A1804D9 for ; Mon, 28 Jun 2021 09:49:08 -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,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-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) (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 09:49:07 -0700 (PDT) Received: by mail-yb1-f172.google.com with SMTP id b64so19551552yba.0 for ; Mon, 28 Jun 2021 09:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=datadoghq.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9snwXeiM+knDlNHrs0Wggtuhs+n7koLipCMCtF0RB/0=; b=TiAmZwgYDWcWqhkZFllHj/4qg5yq+iRU9VBNbsgL9RkQsDDCPb1BliQPHHnSTaG3r3 9xuSHrwwPsOp+NlCHM1TlSsR5jafeo0bENox0ev3WRM3+L9VfrQboQd70xvSYw0ZiXTp f557/HvRlb6KW9Mbna4sZcsygbZygvmYxsnWs= 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:content-transfer-encoding; bh=9snwXeiM+knDlNHrs0Wggtuhs+n7koLipCMCtF0RB/0=; b=Jk4jyt5bE/uhS+oQm9YSqDC31KMDsgo5g21FTtxna12Gg76/KZMLHvjEDE29/ZgQ3G HHA61aBwPDTmhbaC7tqmp/LwlCqNH18JpWH/kVqA9GcVXR/dd6/OQ/weo6Fkdpu+Tv1e z4XEe7C74pbniKeFc4HNTGqZgDWtmkuOZf224IyewraLPAIL+uBv9axZBZO1ae4HpNAT hjEyk3crICMD3715lBbkOKZL0kbUav52Yl+AHFjFwrIAACuVjvYNNJ0pEI3janU6Embk XGGuY7+AllqHFbH29czgPuud0abR4F3bJ6QmcF2k2sQx6kOaV0X5lO5zkdPlzkX0Pay2 JBDg== X-Gm-Message-State: AOAM533D/+M9O8ZICckRZzZ04diDfwMGra1oBHvpJ3Y6fSPPQxpf0h9G JPGn1Um87HL9WH48pNLz22fSfGyWuEAzFZ2vIsLS1Q== X-Google-Smtp-Source: ABdhPJwqdJbb0A6oNmHhC/LEfV9DBovXVMUN9ArMfv0kvbxvttHC9uhapsD9Fjqe9C0olQqZl2r0bc9tFh1LiIg5jB4= X-Received: by 2002:a25:b993:: with SMTP id r19mr32775143ybg.445.1624898946926; Mon, 28 Jun 2021 09:49:06 -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: Reply-To: Levi Morrison Date: Mon, 28 Jun 2021 10:48:56 -0600 Message-ID: To: =?UTF-8?Q?Olle_H=C3=A4rstedt?= Cc: Larry Garfield , php internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [Vote] Partial Function Application From: internals@lists.php.net ("Levi Morrison via internals") 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 o= f > > > ... for the variadic placeholder. In the end we decided not to explo= re > > > that, as Nikita explained off-list it was actually more confusing, no= t > > > less, as it would suggest "placeholder for a variadic" rather than "a > > > placeholder that is variadic." Otherwise, it's just more typing. Th= e > > > 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 p= ost > > 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= -php > > > > 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 h= ad > > on there, ever), so I think the demand for it is definitely there in th= e > > 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 PH= P? > 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 t= ypes? 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.