Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114549 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 91353 invoked from network); 20 May 2021 22:48:21 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 20 May 2021 22:48:21 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 16B1B1804B1 for ; Thu, 20 May 2021 15:58:29 -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_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) (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 ; Thu, 20 May 2021 15:58:28 -0700 (PDT) Received: by mail-oi1-f170.google.com with SMTP id z3so17939112oib.5 for ; Thu, 20 May 2021 15:58:28 -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=n/6EUm70pCbL1oTm0fAmgo/aVvHFhyb7qM2sO5O4+1E=; b=sxiBnrqvsFiKrbWRBwvou595S6/B1Ga1DAoFa/sgcUFuo3F95426j5PqA1dlOIk9FQ iwir0ShDmQdCwRyMCZ+TPJwa2rVweIWzaHOJFO1urbkgGeh5xd+o1SqCbuA+ChpAl2FP D9s/hbnK5gSwLyIqOuvzSdQKTjbSLXOHr5NnDnPc1KaHzESLTXWz190tok6aoc0XQWDO WyArMz0t4LPNAnbjuCJrE/pTARXsIOU8rcu7099rwaFMJADF1pSnb73P0wmtfdIzsMnT /XZW29Ex3dizzVh4QGom60klBKworpbHOrpsG4Aosmw/dImITAIR75ZP9ZEDtlgdzjeC bxRQ== 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=n/6EUm70pCbL1oTm0fAmgo/aVvHFhyb7qM2sO5O4+1E=; b=Br1AkBGgw3jBeVH2S5VQZ+cHgtCytutRQ3FFtNCsjj1+KMj1bCaCOPk+XxtadBP2ff AOOWNoK8fNnhWTuhMu3geKcWlLPMdRcDpbJCJO69IP+QT3yhzeg+k5J8v/htUIvB8wj3 qXcLjhwh+T7ZL5/M1ddJ+8clGBIlo7sywxMnc0uwJaScUcVBN+yyOq5597SbtvG3ilS3 qU104s5uZdnp7Oxd6eWl9Zi53/vIQGAvqxym+/TC7vYm8EHuXbOo1xBhMK85k+g5SDDF 2/MIFeQhsBU6U5d8AYw+zch1RljyOMx2RRQtO1sNYqbr5wvZjjKrfOjV9vccGnQP01WV aKJw== X-Gm-Message-State: AOAM531d70I9XyoMEOgKmcIzhZ7KyPfUhVJBjOPp/EWs0nk3wz2wJ/o5 ExLVPda0Vg4I20Gi6nJuyhfmjYkVzIkeaHX4id3hcy+JaLc= X-Google-Smtp-Source: ABdhPJxXyMwPNw9Jc5zvGSwB/JiqEuqLvwoOwZyDY+VEEqtWB5iLGZLmAG7yGLXFXnpo+zyYE8Sl+EFoEdbvDQ2HJjo= X-Received: by 2002:a54:458b:: with SMTP id z11mr4592369oib.177.1621551506304; Thu, 20 May 2021 15:58:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 20 May 2021 23:58:15 +0100 Message-ID: To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="00000000000084b03005c2cae150" Subject: Re: [PHP-DEV] [RFC] First-class callable syntax From: davidgebler@gmail.com (David Gebler) --00000000000084b03005c2cae150 Content-Type: text/plain; charset="UTF-8" On Thu, May 20, 2021 at 8:38 PM Larry Garfield wrote: > > There's been a lot of rapid iteration, experimentation, and rejection. > The most recent alternatives are this one from Levi: > > https://gist.github.com/morrisonlevi/f7cf949c02f5b9653048e9c52dd3cbfd > > And this one from me: > > https://gist.github.com/Crell/ead27e7319e41ba98b166aba89fcd7e8 > > Intuitively, I think I prefer your algorithm as these are written up. Levi's allows for named placeholders which I'm sure for some users is a big draw. But I think what you're proposing is cleaner and will be better understood. It resolves a lot of the concerns which came up in the PFA thread, striking a reasonable balance between benefit and simplicity. Either way suggests compatibility with Nikita's proposal, assuming use of the spread operator as the implemented syntax. For this RFC in isolation, though, it does loosely concern me as a user the proposed syntax looks more like a function call. I won't bog anyone down arguing the syntax, it's a minor detail for users to get used to in the grand scheme of things and I'd definitely rather it was possible to build the more powerful PFA on top than bin that off, or end up with a convoluted PHP providing competing ways of doing the same thing. > * Named arguments make things more complicated. One of the questions is > whether named placeholders should be supported or not. And if they are, > does that mean you can effectively reorder the arguments in the partial > application, and what does that mean for usability. It gets complicated > and scope-creepy fast. > I do share the concern about named arguments and it's one of the reasons I prefer your proposal. I think scaling back the scope a little bit is exactly what's needed right now. > While I agree Nikita's RFC here would be an improvement over 8.0, I don't > think throwing in the towel on PFA yet is a good idea. It's a much more > robust and powerful approach that still gets us the "first class callable" > syntax we all want (at least I assume we all do), and lots of additional > power to boot. I'd rather see us try to drive PFA home to completion. If > that proves impossible by early July, then this RFC would still get us > something this cycle, as long as the syntax is still compatible with PFA. > I think this is very sensible, I can only really say I'd rather have Nikita's proposal land in 8.1 and PFAs in 9.0 done right than have PFAs in 8.1 but in a way which is confusing, ambiguous or problematic for users, or not covering reasonable expected use cases. --00000000000084b03005c2cae150--