Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113755 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 61753 invoked from network); 25 Mar 2021 05:16:41 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 25 Mar 2021 05:16:41 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D3B4C1804D0 for ; Wed, 24 Mar 2021 22:12:37 -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.2 required=5.0 tests=BAYES_20,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-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (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 ; Wed, 24 Mar 2021 22:12:37 -0700 (PDT) Received: by mail-lf1-f53.google.com with SMTP id i26so692359lfl.1 for ; Wed, 24 Mar 2021 22:12:37 -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=hPRfCLKD/Gcxcys9Is3rcjF4HIMCYld/K3vsUl+AFrg=; b=HWTBE95xYo2jOk8MD4e4wo1mIoAvIrw8omqCInlL70UOdxrSdiBl8ZiKjaa/83SLJw 828vFZGCYQBua86qsAQaNPka3reonLiaomhbcnuvD011XL+rHO8DF/PajaERq5B0l6au cWsrSstlJrEp9BLOiSi4SVaLZwueAwZHtmDG7GuuOJ/WJR5B00AlzxcrFWlXZCH+vRJt nsKW3CsSRpv4rPGghYHABIg5B949xTMNvMNuoGtRbqJido0hPWza+U0fZLrXeO+wi4LX cgM6nEQhX3KOdKRZEYMehP/WIPmVWVWies6apbA6digF1SDLBEZ44DlYRbhghJCSeKxM jLJQ== 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=hPRfCLKD/Gcxcys9Is3rcjF4HIMCYld/K3vsUl+AFrg=; b=a/6JZAP93KY4+dSoaGti24+WY/qTexROWFHubqV9PVdPmIWNQuRnGyEIZ3/+NK5C9/ OmECvfJ5BzQbam3JSQrB55XpSg9bu1GjScVMS9vDOwLUalugbLCvuGHuE81yFIyVYX57 5T+Axxyn4v43SQLozEelVPJiMivYMIq4UhW8K2R6d01s7cW2d1n3+1wafJLSvgTEnWIx SbAsEGj7ZXTsRFpm0hs0DBJboaMXG92ZBsNm6jrL3dThEIj1ybxZTAh2W8jnxuz67C5h +W+NSfp0uN5ysggMeGveBZ/HzDqWsba3+fSGWMcCtXfY5OPS2/D59o8Ot3VUmFluarSy 0Q3g== X-Gm-Message-State: AOAM533YRVBV+oQB5UwK6lziXfeeo/mFskrqN13sNzsJ+NwEGIVeW7HF 4WhR0BzTXxPmKU9R16ZjKlY204yEyuGcfwU/PpQ= X-Google-Smtp-Source: ABdhPJw98XDOnpmqttEbjNX5K9UsgZ7sPHn9W+cIt/RWS1132H71SFUim80I8/3LThnUgcYhgZbEOlOlpf9O2CXiyVo= X-Received: by 2002:a05:6512:314d:: with SMTP id s13mr3752356lfi.95.1616649153868; Wed, 24 Mar 2021 22:12:33 -0700 (PDT) MIME-Version: 1.0 References: <44ac7866-75ef-44ab-a5f9-4e571652b5e6@www.fastmail.com> In-Reply-To: <44ac7866-75ef-44ab-a5f9-4e571652b5e6@www.fastmail.com> Date: Wed, 24 Mar 2021 22:12:22 -0700 Message-ID: To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="0000000000008af89405be557601" Subject: Re: [PHP-DEV] [RFC] Short functions, take 2 From: sarkedev@gmail.com (Peter Stalman) --0000000000008af89405be557601 Content-Type: text/plain; charset="UTF-8" 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. 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? 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. Thanks, Peter P.S. I also don't like PSR-12. Allman braces and tabs for life. --0000000000008af89405be557601--