Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113796 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 70056 invoked from network); 25 Mar 2021 20:13:09 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 25 Mar 2021 20:13:09 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 29D301804D0 for ; Thu, 25 Mar 2021 13:09:14 -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, 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-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) (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 13:09:13 -0700 (PDT) Received: by mail-lj1-f171.google.com with SMTP id r20so4780349ljk.4 for ; Thu, 25 Mar 2021 13:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9iRaNEE6gD8I3bVTxWVRpd2Xn1CuPF09fzgeZWEA1Q4=; b=puanFJFNzMo6lz3dVQOKtHnc0aB7GVGpR4pAExs44xcbxcCyXh+rAy7qDdXcfTMPV0 5L91Vj6WSCYWXiJT9o5dkkJItaCTuxtPtyT2H49II9xOGc3ZzoIYaXTVIxauz44DbRVX 9aD8Cy7kYHxosery6ImEEWVVVm6nDfFvR738Fy75iBZks34VDD3WTsJFf41s4e0bhilp kuaLjlb1eHl4ecgumqyxb3x9z8XCgaqHBmCJRyyhkqp1lfH3lL7irhoFSM9+uqlSeN1z lVRBv+rcgudyx1qMZq2FWNUcmjWDTwxsGPm0hr5uGSfAeUAXTsmoDGN8j4W/GZVbPxqr tejA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9iRaNEE6gD8I3bVTxWVRpd2Xn1CuPF09fzgeZWEA1Q4=; b=Tsnr6tM5//a6UvUi0SBEDCZg9ZlY/M3oPC4cdqRLSZOQVlWWe5B1IJBQuYBT6aLFHx xhbshAu+yIG7NutAqpduBdAtryh3dXiJ3nsRR+j8dyPAQ4VLE2G6BE/oIoElXq4rVFKF 43dTEQKevLz5e90ZJzXZpj+CFp1g/l/q+Bdgm75FsWswoFZz7N4EUE9KieLKiVPQ/+tS xmG9EgEu2B+nY7jWCX6wZmJSwDpSqyuR/jy0842XIo7dHyfqqnZPfyVoKm9gGgCzhCj2 xNAlmYgcRkAYF+ThSjWM0+KaIzVRqQ7WYNBz3A7AjS+V9rFJkzeN6Fg+4Y2HSXFbwtT1 XYEw== X-Gm-Message-State: AOAM53052f+dIulKfsj3h6T5Gkn5vdJwBOHqJdeeUWNVY10yJAXBxgFA ot3WhoMzggq9z6XhyRM9QyCkj/HTpwx/IQLD5QCxeSlH X-Google-Smtp-Source: ABdhPJwAPk3MaPrProeQjOwWIU9B+vD9QOt+wzbfxV5KPc/OI6QX74VdPGpw+PBJSRgj2nrk18rdH30hcPKbE1tSSj4= X-Received: by 2002:a05:651c:85:: with SMTP id 5mr6916041ljq.470.1616702951086; Thu, 25 Mar 2021 13:09:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:5f8f:0:0:0:0:0 with HTTP; Thu, 25 Mar 2021 13:09:10 -0700 (PDT) In-Reply-To: <15AE4315-A456-4ED8-990A-49EBD76C5B46@newclarity.net> 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> <15AE4315-A456-4ED8-990A-49EBD76C5B46@newclarity.net> Date: Thu, 25 Mar 2021 21:09:10 +0100 Message-ID: To: Mike Schinkel Cc: PHP internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2 From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=) 2021-03-25 17:49 GMT+01:00, Mike Schinkel : >> On Mar 25, 2021, at 11:22 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 >>>>> going >>>>> 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]. >>>>> For >>>>> 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 o= ne >>> 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 agree that readable is more important than writable, but shorter also d= oes > not necessarily mean it is *less* readable, either. Sure. The brain removes noise and reads in "symbols" anyway (where "fn" or "function" is a symbol of size 1). A more important aspect of readability is the cognitive load on short-term memory, or how many "chunks" the programmer has to keep in memory to understand a piece of code. In this case, I think immutability and local scope helps a lot, of which PHP has neither. Or maybe predictability of the scope? All language quirks hurt readability. I never had a problem with scope in JS, despite it lacking immutability and only recently got proper block scope. Maybe more important than explicit/implicit capturing of scope is to keep your functions short...? In our legacy code-base, we have functions thousands of lines long. I can see auto-capturing being a problem there, but that's because of the technical debt and not the feature itself, I guess. Will our juniors realize that, tho? Never the less, the need to include 5+ variables in your closure - code smell? I stated above that command pattern and data-transfer objects are probably better, and that's why I think the example in the RFC is not motivating enough. The question is not "what do I want to be able to write", but rather "what do I want to be forced to read [by less qualified programmers]". > For some people, shorter makes it more readable because there is less to > read and more whitespace surrounding it. Ironically readability is why I > prefer fn() w/autocapture over "function(...) use (...) {...}." > > Also, it appears you may be discounting that readablity evolves as people= 's > familiarity with a new syntax increases. For example, I found RegEx > completely unreadable for a long time, but today I find them completely > readable because I now understand them. Have you already considered wheth= er > or not you would still find fn() w/autocapture less readable even after y= ou > have more time and experience seeing it in other people's code, and decid= ed > that you would still find it less readable? > > I do recognize that ever developer has their own preference and I am sens= ing > that your preference is for more verbose syntax, at least in this case? I= f > that is true shouldn't you just state that more verbose is your preferenc= e > and if you have a vote then vote against the RFC? Isn't it unfair to > implictly assert that "shorter is less readable" when really it is just a > preference? > > -Mike See above. (I have no voting power.) Olle