Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112146 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 65626 invoked from network); 29 Oct 2020 23:30:11 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 29 Oct 2020 23:30:11 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 826F6180531 for ; Thu, 29 Oct 2020 15:49:24 -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_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (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, 29 Oct 2020 15:49:23 -0700 (PDT) Received: by mail-ot1-f51.google.com with SMTP id f37so3865174otf.12 for ; Thu, 29 Oct 2020 15:49:23 -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=/udfq45J7waa18wUtDYjC0Yt1sIsulFPxRY6TNmOA58=; b=q0Qno79MeRPCMMBjJv+goQH0LkAVsMczPsD/EUOyqx0GP8Bc49fbrZjXWxwUsusdWU hu7H7xzUhXjdEWN988OscT7xl5EXqbvbg97bnD5vpoGroRW7JorBCKGqvQI63DJWBoC5 mx1j9tK3RAOF8HYqr6JDHTWWsWmsFqoT0+H6eAwclxXUnoblOAJV1Hg0cj68Eyc92DVD vSF7OIFRjzCOAVDpVlWEUUAkXx7FTd7n7wSLPr+I3NhO+hdFoaPOY+xSX7D682jowW8I EoQ2R2TpTTsis59CioNo7zhOih14OqpdgaKboWRVkjR6rngoXHWPm0yJgxzfN5mLNAYa rLFw== 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=/udfq45J7waa18wUtDYjC0Yt1sIsulFPxRY6TNmOA58=; b=dvadieyM3RymGTrSTDA6jD6dKa6AfqHvteO8Gudk1nQaRYabIvFQOHiqp8Fw4qLoih /Y3Ct3CPCmOaATjRBHV+zG9tGPx6bUKq48YWoJt1zg3KJwuvv1sKFeGqhJxhpE671u43 H6TuiqxfPgeXKHFxqVGBCA3j7nmM1hJsOpPwea3dQWM08TISkG4rlbKQ50QzqZlXCr54 0mNWqn+JjEqH2mrdM1OFSlzhIiC+IlwrY3DeGxNmPe5DN3hcXJDL4F7B7D73e2h0GEpM sqaMFZpmSVeq2too86kFJX4zK4FKi9z5ksTx14jcQ+etkjBS4D4Qy3b0VV4lURCUwsjC sxzQ== X-Gm-Message-State: AOAM5330sO5UJykhh2QHiPkNSQvNua9ZBDNd8X2Fsmewm8bMJmjm6mH9 f7uuq3oX4rvIGuSkdkXnZW+VVo/HmeyhDCalAGM= X-Google-Smtp-Source: ABdhPJzb60EsL9vm/gNg5FLvh3yUbhEMhNmFg886zT01w7h7FGIAEg7wjpAZLGL5mrIHCs/v44SmRwISIsnA7bsBo58= X-Received: by 2002:a9d:6d15:: with SMTP id o21mr5191635otp.232.1604011760571; Thu, 29 Oct 2020 15:49:20 -0700 (PDT) MIME-Version: 1.0 References: <446c9894-191f-e53b-4534-31c4e7b91d7b@gmail.com> <881e2335-5f81-0d79-6a17-06bc20f14223@gmx.net> <873361ff-02c8-b9df-9b7a-c9e89e25a880@gmx.net> <7F014A40-2D47-4DA6-8A38-59518218F9CA@stitcher.io> <9A58B811-37C4-46C8-A7A9-B558752362F3@stitcher.io> In-Reply-To: Date: Thu, 29 Oct 2020 23:49:09 +0100 Message-ID: To: "G. P. B." Cc: Brent Roose , PHP internals Content-Type: multipart/alternative; boundary="0000000000003457a905b2d717c0" Subject: Re: [PHP-DEV] RFC: Support for multi-line arrow functions From: benjamin.morel@gmail.com (Benjamin Morel) --0000000000003457a905b2d717c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 6 Oct 2020 at 14:09, G. P. B. wrote: > And once *again* short-closure don't *just* have the auto-import of the > outer scope going for it. > The other main features of the short closure are not applicable to a bloc= k > syntax. > - the fact that there is an implicit return > - it is a single expression, > **no* braces therefore it doesn't look like it creates a new scope.* > I'd like to come back to this. Actually there is a precedent in PHP where braces don't create a new scope: $a =3D 1; { $a++; } echo $a; // 2 I'm not sure why this syntax was allowed in the first place, but it is. So I wouldn't be bothered if we create yet another case of block not creating a new scope. I'd like to emphasize the use case brought by Andreas Leathley: transactional scope. I'm doing more and more of this these days, and I find it very appealing: $connection->transactional(function() { // send raw SQL queries // or create a scoped EntityManager // etc. }); This is, IMO, the only way to easily guarantee that any `return` will commit the transaction, and any `throw` will roll it back. Otherwise, you must remember to wrap your *whole* block with try {} and catch/rollback/rethrow. That's a lot of clutter that you'll typically want to avoid when you're repeating this in each and every method of every service. Now, the example above doesn't convey the purpose of the RFC on its own. Let's put it into context, here is how one of my service methods looks like= : return $connection->transactional(function() use ($authorId, $activityId, $parentId, $comment) { ... and this is not the largest one. Let's see how it would look like with this proposal: return $connection->transactional(fn() =3D> { This may not look like a big gain for you, but this would make all my services look MUCH cleaner. And I'm not worried about scope leaking: usually, the closure takes up most of my service method. =E2=80=94 Benjamin --0000000000003457a905b2d717c0--