Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113777 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 26893 invoked from network); 25 Mar 2021 15:35:45 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 25 Mar 2021 15:35:45 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1165A1804C0 for ; Thu, 25 Mar 2021 08:31:48 -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-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) (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, 25 Mar 2021 08:31:47 -0700 (PDT) Received: by mail-ua1-f44.google.com with SMTP id y20so428374uay.6 for ; Thu, 25 Mar 2021 08:31:47 -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=8lvaA1MVZg2mKhG69tiUnu5gwmeBWCjlLv3FoLWTxUo=; b=s8OOnA7uuP1lP2k1B0SqwWa0YwBFkj8glkCn6lnYPbnhb+EHBiv5E3tNDPFgrK2zt/ +DwF1nPJapykwKPhyUP3Rh/hQUqk0tPNEDcCiug6lM/Z00XILWGyETqQbE7pz83mdY6b ZBJAJ27n4EHG5j7whtP2mnMPJtUHBCDMmz8+eXwZ317BcWZa/oXU491wF1NKoUaonK05 /X/C/AYGv/KXJ9mnbrb+h+r+st2/e+G8Ie7H4nZKPnKoLuMsBrhW25vdkwyME1oSmyhi LWZm5fLmZaXDJFlirQSXBaY5nWkEHpAgZvdj07K1rJf+loem+426nEIvtKKnpiF1ciAx JtAw== 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=8lvaA1MVZg2mKhG69tiUnu5gwmeBWCjlLv3FoLWTxUo=; b=sK61BthPI0LqI/7gUqbxYqD9TOL0l2tpnlgjKPxPo0U4/w35m/EZv0JFqmrY0j6mhH 30AdBILRP3fxc82nDmzpx+4DpXDCbBMWSsgcGm5qo/Ts3vVm7xQjWduUKPIDymjDjWBB ql7drkJCmVGMdN0MDBMMb0hyU9u24/DOUh5stwuYrQ0GHMiL7OKZ7XcUId5rFYl+/h3Y j7s0PM1p/vPrPsMmn8duldZg4dO+ufWgQf1xXS9m0zMJgwZ/R6QOPO0Mqzc11ZS07Tz2 tOeM8tyEbj66XmElVwinGapisZepSblkLYf7NTmTL9SuWFcw2EKBGh8ZYn5RPPyBrgAh 6/yw== X-Gm-Message-State: AOAM530ajo22xSW0wqzoyDDd2w/7boRymAzdZtRpI/vgZBK+g3PGcX/Y Hd4l/UgzNlOyoI/CCW7z7ZAzkcJD8VKPbRwrTXk= X-Google-Smtp-Source: ABdhPJxNB2z3fLwvsKhrg4HG1HZYIum+vx4vBbsT/PG8Yna28UcS0SMF3v7WdSv+Paeyj1/NXR0c41LyBYK62iJ7iIc= X-Received: by 2002:ab0:20d9:: with SMTP id z25mr5129592ual.33.1616686302997; Thu, 25 Mar 2021 08:31:42 -0700 (PDT) MIME-Version: 1.0 References: <88c9eb5f-f80c-4869-b7f8-1b58b9e2eaa3@www.fastmail.com> <4DC3B66E-A91A-4AA9-8872-8EE9DE92C2D4@cschneid.com> <8c72c162-83c0-7c7f-2fa7-4fbe3fb30a4a@gmail.com> <605bae82.1c69fb81.f49f7.d11eSMTPIN_ADDED_MISSING@mx.google.com> <919e30e7-3e5e-d955-7bb4-1e1b5825cdd1@gmail.com> <635DD146-FC6F-4991-8D2C-5A6B492722D5@newclarity.net> <734f12de-da98-6b76-c2fe-8682f4d177aa@gmail.com> <36E45DD6-E2BD-4801-BAAE-4355C83D1AC3@newclarity.net> In-Reply-To: Date: Thu, 25 Mar 2021 11:31:31 -0400 Message-ID: To: =?UTF-8?Q?Olle_H=C3=A4rstedt?= Cc: Mike Schinkel , Rowan Tommins , PHP internals Content-Type: multipart/alternative; boundary="000000000000cdaf3205be5e1c19" Subject: Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2 From: chasepeeler@gmail.com (Chase Peeler) --000000000000cdaf3205be5e1c19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 25, 2021 at 11:23 AM Olle H=C3=A4rstedt wrote: > 2021-03-25 16:02 GMT+01:00, Mike Schinkel : > > > > > >> On Mar 25, 2021, at 10:41 AM, Rowan Tommins > >> wrote: > >> > >> On 25/03/2021 12:31, Nuno Maduro wrote: > >> > >>> The reason why we believe the vast majority of PHP Developers are goi= ng > >>> to > >>> appreciate this RFC is because multi-line short closures (aka > >>> Auto-capturing multi-statement closures) *are more simple, shorter to > >>> write, and prettier to read *=E2=80=94 and the community love these c= hanges as > >>> proven on "property promotions", "one-line short closures", etc. > >> > >> > >> My main point was that the RFC needs to spell out this argument, rathe= r > >> than taking it for granted that everyone agrees on "those situations > where > >> that is warranted". > >> > >> Most of the current text should be summarised in a "syntax choices" > >> section somewhere near the end. I would like to see much more space > >> devoted to: > >> > >> * Why we need this feature. What has changed since it was left out of > the > >> arrow functions RFC? What problems is it addressing? Why do you think = it > >> is the best approach to those problems? > >> * The exact semantics proposed: How will the variables to be captured = be > >> determined? Will it distinguish variables which are written before > they're > >> read, and if so how is that defined? Can auto-capturing closures be > >> nested, i.e. will "fn() { return fn() { echo $a; } }" capture $a from > the > >> outermost scope? And so on... > >> > >> > >>> Besides, one advantage of this RFC is that it is consistent with the > >>> current syntax of the language and with the short-functions RFC[2]. F= or > >>> example, by proposing that "fn" keyword indicates a function will > >>> auto-capture variables, by value. > >> > >> > >> While it's a cute rationalisation, there's no intuitive reason why "fn= " > >> should have that meaning; we could pick any aspect of the current arro= w > >> function syntax and say "the 'fn' keyword means that". > >> > >> > >> > >>> On the other hand "use (*)" has no usages / or current meaning in the > >>> language. > >> > >> > >> This is a straw man argument. I could equally say that "fn() { } has n= o > >> usages or current meaning in the language" - of course it doesn't, we > >> haven't added it yet! > >> > >> The "function use() {}" part of "function use(*) {}" has a > >> well-established meaning, and "*" to mean "everything" is a notation > >> developers are likely to be very familiar with. > >> > >> The two disadvantages I see with using "fn" as proposed are: > >> > >> * Because it's shorter, people will decide it's the "better" version, > when > >> they don't actually need any variable capture. An explicit syntax like > >> "use(*)" instead makes this a deliberate choice. > > > > And yet adding " use (*)" makes the syntax longer, which goes against > one of > > the goals many people have for it: to be shorter. > > I don't understand why this is a target in the first place. Shorter > does not mean more readable, and readable is more important than > writable. > I'm a bit confused on why "shorter" is such an important requirement as well. We aren't in a situation where memory is at a premium and we have to take shortcuts to get our code to fit in the available storage. I also assume that none of us are such slow typers that there is a material difference between the options. On top of that, most IDEs worth anything have autocomplete options that make it moot. I agree that shorter definitely does not always mean more readable. If so, we'd be taught to give all of our functions and variables single character names instead of names that were descriptive. I'm totally in favor of auto capture with the fn() syntax, but I think the fact that its shorter is not the best argument to support it. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > --=20 Chase Peeler chasepeeler@gmail.com --000000000000cdaf3205be5e1c19--