Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112013
MIME-Version: 1.0
References: <CALZWoqU_qQQiQ5O6Pa8Upxo2FYZ2hpMA0dy9=CZndeEFsijgxA@mail.gmail.com>
 <446c9894-191f-e53b-4534-31c4e7b91d7b@gmail.com> <881e2335-5f81-0d79-6a17-06bc20f14223@gmx.net>
 <CADK1yX+0EDTuZ2Sg20_xJH02zLC15Ks1jcYR5zfECdnUBsfUFQ@mail.gmail.com>
 <873361ff-02c8-b9df-9b7a-c9e89e25a880@gmx.net> <7F014A40-2D47-4DA6-8A38-59518218F9CA@stitcher.io>
 <CAFPFaMKSVuWp9ZmdUQavE6vT=qokZpBfmrMc9=Wkot=r5fiJHA@mail.gmail.com> <9A58B811-37C4-46C8-A7A9-B558752362F3@stitcher.io>
In-Reply-To: <9A58B811-37C4-46C8-A7A9-B558752362F3@stitcher.io>
Date: Tue, 6 Oct 2020 13:09:01 +0100
Message-ID: <CAFPFaM+aeqrvaPpAUgZHV703PGcQ=puadeAKQkctxR=P6bKcwg@mail.gmail.com>
To: Brent Roose <brendt@stitcher.io>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009d5f9805b0ff7770"
Subject: Re: [PHP-DEV] RFC: Support for multi-line arrow functions
From: george.banyard@gmail.com ("G. P. B.")

--0000000000009d5f9805b0ff7770
Content-Type: text/plain; charset="UTF-8"

On Tue, 6 Oct 2020 at 12:20, Brent Roose <brendt@stitcher.io> wrote:

> The point of short closures, regardless of single line or multi line, is
> addressed (and agreed upon by the RFC votes) in the first pararaph of the
> RFC [1]. I'm not sure if I can add anything useful rather than saying "it's
> nice to be able to write more consise code. It feels a little more smooth".
>

The thing is, the RFC voters have agreed on single-*expression*, there is a
high likelihood that if multi-line
(i.e. multiple statements/expression) support was included in this RFC it
would have failed.
Why do I think this? Look at the previous vote:
https://wiki.php.net/rfc/short_closures
So your conclusion about what the voters agreed is completely nonsensical
here.


> There's actually one more argument to be made: they would make the use of
> closures more consistent for those of who _prefer_ short closures. Now
> you're forced to mix up both the short and long syntax. As an example, I
> use Laravel's collections [2] which provide a functional API to interact
> with lists of data. You often chain these calls, and are able to use short
> closures like 80% of the time, but sometimes you're forced to use the
> longer syntax.
>
> So that's my two arguments for multi-line closures
>
> - Making code less verbose, which is the _same_ goal of single-line short
> closures, which was accepted by the vast majority of PHP
> - Consistency with already existing single-line short closures
>

Ignoring the first point, refer back to the previous paragraph.
What consistency is there if there is no implicit return in the block form?
Sure it is annoying that for a 2-liner, where you probably won't "forget"
about
the fact that you are importing the outer scope it is annoying that you
need to
go the longer route. But that's not a sufficient argument IMHO.


> My point is that PHP is evolving towards a modern language, and with that
> come syntax changes that not everyone likes or wants to use. @ for
> attributes isn't chosen because it simply isn't possible to support that
> syntax, not because of what the community _and_ internals want or don't
> want. I don't think of this as a counter argument to my original point: PHP
> has seen a significant increase in syntax sugar additions over the past few
> years. If no one wanted those, they woulnd't have been voted in. Would you
> like to address that argument? Why are promoted properties, single-line
> short closures, named argument, etc added besides that there's a "want" for
> them?
>

The core difference here is that it doesn't change a *fundamental* aspect
of the language
(or in the case of single-expression closure it changes 3 aspects making
them very
special), you might not like this aspect but it is still present.


Obviously nothing is necessary, we could write assembler style with only
goto statements.

That's exactly what I'm saying! It's ok to add syntax to make a developer's
> life easier. There are cases where that's a good enough argument.
>

And this is not one of them, at least for me, and I don't think I'm alone
here.


> Why was auto capture added to single line short closures last year? We've
> had this discussion before, and the majority of internals voted "yes" back
> then. So instead of only re-iterating the same discussion, why not provide
> Nuno with useful feedback as well?
>

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 block
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.

You ignoring these facets which are key benefits which only apply to the
short closure case, to imply
the extension to multi-line is a "no-brainer" is not making a case for it.

My opinion is already that the way PHP does closures is the Sane Way To Do
It TM,
you have a dependency on a variable therefore you need to specify it, is
IMHO a good thing.

Do other languages function just fine with the opposite behaviour, sure. At
the same time Java
has implicit nullable type arguments and people deal with it.


Best regards

George P. Banyard

--0000000000009d5f9805b0ff7770--