Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112116 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 92983 invoked from network); 26 Oct 2020 10:26:25 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 26 Oct 2020 10:26:25 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D933C180508 for ; Mon, 26 Oct 2020 02:44:44 -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-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (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 ; Mon, 26 Oct 2020 02:44:44 -0700 (PDT) Received: by mail-lj1-f173.google.com with SMTP id 23so9041620ljv.7 for ; Mon, 26 Oct 2020 02:44:44 -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=Hzgku0Xvc9pE3WFp57+1SuDT0+nicinbc0PPuppF3LI=; b=VoDYF7Pu3ZHiJmVG3QfVg9gzCVfE3yHT+HvRLGLsThXdhilu4PeUH3oXJcnwNq/yzs K8YEZ6x0sGi0G6jWmMhKkkmQWmDPJplTMKVO0MuzZdZcNC2gUMU2fn/b6+aSuSZiRQUT R/lXfouDGJp1Pv91i7m7cQ3xzC6MtQOFGqbasWRI9WWflAevc6xRGutgyhr+OmVOgTVg 4n2Co2THcEV8fxz5BFk9PqlLn/S2w66yCOjjPWkqwKmthNLNfoBOpPZUDbCBrkROvO/J dg27wGDO07TXwgnVSamn0+6H1aUGTnuihEsmjHcLEFJFd28cnJYppYh/UHSoi5/UilA7 o36A== 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=Hzgku0Xvc9pE3WFp57+1SuDT0+nicinbc0PPuppF3LI=; b=H9vnisMJGZrjNcJx5TqNetFP/UP7UAHFsLr2GmxkekoW+hgH/AH9ms0x2thj1BK3uB zGHTk33VfThHjvdWzbjLGJXdFxcUpRgWOwfXhW38QsSDVZAtYShx14QHx7Npz5ZoWFME 5/jSO05YmY2GVr0mf8OjAAOJEotMdgklg0iOH5fz235mdV3NKBB96PFE8bmJoTbu/hYz dOd/qZTT9ynHyWP4PLhF1JlHbanKFbCblzcO3oYD0cOWYebzHgh1jjqvKXGROzUficDh hM7kO0lLnRMVvuDjIDwlT4pLSEKekJdcXQ2ArPdUI9DAA6ehgwmUMOtyAd5RyOndhJ0h mgOA== X-Gm-Message-State: AOAM532+ifXpBlB57hYS1hhrhlG6NqvI02bQ/0yfkB0x7SR1qUkwrDXA dAxk5ExgXGxoUeZJM4hZ+jNW7zpnCAUq9RXHV2UH2w+CXhHmIw== X-Google-Smtp-Source: ABdhPJxE4J+6MROh+oXLEPUD6SyMSsZLdbt557LCVCqWRo4WoQu9Wqiv7uhaJUEQBlsiAlMjvuKh35/Un/GxoxN1eHQ= X-Received: by 2002:a2e:b04a:: with SMTP id d10mr5784818ljl.81.1603705482727; Mon, 26 Oct 2020 02:44:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 26 Oct 2020 10:44:22 +0100 Message-ID: To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="0000000000009f55e605b28fc74e" Subject: Re: [PHP-DEV] [RFC] Short-function syntax From: nikita.ppv@gmail.com (Nikita Popov) --0000000000009f55e605b28fc74e Content-Type: text/plain; charset="UTF-8" On Tue, Oct 20, 2020 at 8:20 PM Larry Garfield wrote: > A while back, Nikita mentioned that it should now be easy to offer an > abbreviated syntax for functions that are just a single expression. I > decided to take a crack at it and it turns out he was right. I thus offer > this RFC: > > https://wiki.php.net/rfc/short-functions > > Hopefully I made a decent enough case for it. It's entirely a convenience > factor, but I think for many OOP cases (getter methods and factored out > operations) and functional cases (where functions should generally be a > single expression conceptually) it does make the code nicer, more compact, > and more readable. > > *dons flame retardant suit* > Overall, I do not like this proposal. I can see the appeal, and I can also see a (rather weak) consistency argument for it, but ultimately I think this will do more harm than good. It introduces a second way to write the same thing, without providing a major saving in brevity. You might try to argue the same about arrow functions, but I think the relative difference is much more significant there. If we take a class like this: class X { public function getFoo(): int { return $this->foo; } public function setFoo(int $value): void { $this->foo = $value; } public function getBar(): int { return $this->bar; } public function setBar(int $value): void { $this->bar = $value: } } And convert it to the proposed syntax: class X { public function getFoo(): int => $this->foo; public function setFoo(int $value): void { $this->foo = $value; } public function getBar(): int => $this->bar; public function setBar(int $value): void { $this->bar = $value; } } I don't think we've managed to save much screen real estate here, but we did make the code harder to scan: In practice you will always end up mixing the => and the {} notations, which makes it harder to pick out the function bodies. Now, we *could* make this more compact by writing it like this (and this would be a significant saving): class X { public function getFoo(): int => $this->foo; public function setFoo(int $value): int => $this->foo = $value; public function getBar(): int => $this->bar; public function setBar(int $value): int => $this->bar = $value; } Note that this is not the same: The setters now return the value they're setting. You wouldn't ever do this if you used the long-hand notation, but I can bet you that this is going to become something people routinely do with this syntax, because it is the path of least resistance and avoids the awkward syntax mix for getters and setters. Now, in my first example I cheated: I used sane code formatting instead of following PHP-FIGs recommendations (swear words omitted here). If we were writing C++ code, which has different baseline expectations on what acceptable formatting is, this code might have been written compactly as: class X { public function getFoo(): int { return $this->foo; } public function setFoo(int $value): void { $this->foo = $value; } public function getBar(): int { return $this->bar; } public function setBar(int $value): void { $this->bar = $value; } } You'll note that this looks very similar to my last example -- with the difference that it does not butcher the return value of the setters. Which really goes to show that this is not a language problem, but a problem with an unnecessarily verbose coding style guide. If you think that this kind of concise notation is valuable, then I think the style guide should be the first point of attack. I think the most concerning example in the RFC is this one: function pick_one(int $a) => match($a) { 1 => 'One', 2 => 'Two', 3 => 'Three', default => 'More', }; With match, the actual implementation of the function may be quite large, even though it is only a single expression. In this case the (relative) saving is particularly small, and the question of which form you should be using becomes more prominent. I personally wouldn't want to see that code, but that would require drawing a line regarding which types of expressions are acceptable to use with this syntax and which aren't. I also dislike the somewhat subtle requirement for a trailing semicolon after the closing brace in this case -- it makes sense for sure, but it looks wrong at a glance, because it's not immediately apparent that this is not a function block, but a match block. Regards, Nikita --0000000000009f55e605b28fc74e--