Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113781 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 35582 invoked from network); 25 Mar 2021 16:38:19 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 25 Mar 2021 16:38:19 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id CBCA518054A for ; Thu, 25 Mar 2021 09:34:22 -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.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 25 Mar 2021 09:34:22 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5DE3E5C00F9 for ; Thu, 25 Mar 2021 12:34:22 -0400 (EDT) Received: from imap8 ([10.202.2.58]) by compute4.internal (MEProxy); Thu, 25 Mar 2021 12:34:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=hKb822 q4eyzWjFkLKIbuE9NlLOI0612k9DEqHCZ9lh8=; b=GrWKxEWw3VHgVUwSvwX3wo LzeRyqpYEa2WMQTRj7mVXdtuf6sMCjERhXWUcANPzqKzJJ2Bt/ts1GPjaYBgUVei S5wxd4ogYkupk4zpwYA+awT7kJG1Uq30r6vrpKr+eQ40LZtKbZ1LW9uADaJjU4LP Qy8cVZCsm4XpalUlYMtPbEW86cmRXdrLpt5Xwv73QoC9KRxllsYI7Y7vAaZNp5Lj +oTwAZ04QVWu+KMVhNSFOowRo7rzCRro5Opr+jpyl3dF7BeHn9dM91STV/va57Et Sa67ltjpoYcC0BuA6kvhI5DJ6rxrDcWxRCPMddb1tab+S0WfT0Kj1zRDbhqfvhWw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudehtddgledtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdfnrghr rhihucfirghrfhhivghlugdfuceolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtoh hmqeenucggtffrrghtthgvrhhnpeeglefgkeduiedvvdetffeujefftdfhjeeiveehgfff keduveektddvledvvdfffeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 23F203A0842; Thu, 25 Mar 2021 12:34:22 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249 Mime-Version: 1.0 Message-ID: <5f935c8b-0bdd-4605-b7ab-3e1ca7687681@www.fastmail.com> In-Reply-To: References: <44ac7866-75ef-44ab-a5f9-4e571652b5e6@www.fastmail.com> Date: Thu, 25 Mar 2021 11:33:49 -0500 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] [RFC] Short functions, take 2 From: larry@garfieldtech.com ("Larry Garfield") On Thu, Mar 25, 2021, at 12:12 AM, Peter Stalman wrote: > On Wed, Mar 24, 2021 at 5:40 PM Larry Garfield > wrote: > > > In response to the feedback that the savings in typing volume is small, > > that's true but also not the main point. The main point is to allow and > > encourage functions to be written an in "expression style", that is, as > > actual functions and not procedures. As the RFC notes, such use cases are > > increasing, and is likely to increase in PHP, and that's overall a good > > thing for the language. It fits well with a number of recent RFCs both > > passed and proposed, and makes writing functional-style code much more > > natural. > > > > Hi Larry, > > I too am wondering about the space saving aspect; as Levi showed it's quite > easy to currently write functions on one line, which really only cost 7 > more characters. Overall though, I am not a fan of the code getting wider, > and the return statements not lining up as I scroll down the code. In practice, I've found myself writing arrow functions on 2 lines a lot, like this: $f = fn($a, $b): int => $a * $b; I find that very readable, balances height vs width well, and it's a style very popular in functional languages. I expect a lot of short-function uses to do the same, which is a good place to end up. > As for the "expression style" argument, it's a valid one. However, I'm > confused why you submitted this RFC hand-in-hand with the multi-statement > auto-capture closures. Doesn't that contradict the single statement > "expression style" argument? The short-function RFC was originally written early last fall. I put it on hold because there was also on again/off again discussion of auto-capture closures and I was warned to avoid conflicting on the syntax. I only recently got around to connecting with Nuno, who had a PR sitting around for that he'd been ignoring for a while, too. :-) They're separate proposals with their own benefits. They were (re)-presented together mainly to demonstrate that yes, we did think through the syntax to ensure that they fit well together and didn't create confusion around what certain syntax combinations mean. > Overall, I'm not really that much against it, but my only worry is that > while it is slightly less verbose it might create more cluttered code. Try a lot of 2-line functions as above. I think you'll find it's actually quite nice in practice, which is what I'm going for. > > Thanks, > Peter > > P.S. I also don't like PSR-12. Allman braces and tabs for life. Same-line braces FTW, but don't talk to me about tabs. :-P --Larry Garfield