Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87967
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.81 as permitted sender)
Message-ID: <BLU437-SMTP10528B092289CCAD9B4D8AFE26A0@phx.gbl>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
In-Reply-To: <55E4F029.10104@gmail.com>
Date: Tue, 1 Sep 2015 03:04:55 +0200
CC: Nikita Nefedov <inefedor@gmail.com>,
 internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
References: <BLU436-SMTP13020F8CE8795C628BDC665E26B0@phx.gbl> <55E4C19F.4060704@gmail.com> <op.x384rtfxc9evq2@nikita-pc> <55E4F029.10104@gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Short Closures
From: bobwei9@hotmail.com (Bob Weinand)

Hey, thanks for your feedback, but I think you'd got one or two things =
wrong=E2=80=A6

> Am 01.09.2015 um 02:24 schrieb Stanislav Malyshev =
<smalyshev@gmail.com>:
>=20
> Hi!
>=20
>> in this RFC. The main addition (which is extended by that btw) is =
making
>> the syntax shorter. Which, in turn, makes it easier to write and read
>=20
> Shrtr dsnt lwys mks thngs esr 2 rd.
> Sometimes it's quite the opposite.
>=20
>> It would be much easier to read and write with the short syntax:
>>=20
>>  $collection =3D array_filter(array_map((Type $el) ~> =
$el->getStuff(),
>> $collection));
>=20
> I disagree. It is very hard in this syntax so see where function call
> starts and where it ends, especially if there are more that one
> parameter and/or more than one closure.

When I format my code weirdly, I'll have that issue too. Generally, if =
you have problems to read the code, if you'd write it with ~>, just use =
the classical function () use () {} syntax.
I'm not aiming at defacto abolishing the classical syntax (unlike [] =
which seems to have replaced array() everywhere in 5.4+ code...); in =
some contexts it's well readable (compared to ~>), especially, as you =
say, with three or more parameters.
The strong point of this RFC is quick callbacks (like a call to =
array_map), which just have one or two parameters. (Like shown in =
https://wiki.php.net/rfc/short_closures#extracting_data_from_an_array_and_=
summing_it)

Another big benefit is especially in more functional code, with partial =
applications. (Where you chain multiple closures)
I might be wrong, but I feel like the "clumsiness" of the classical =
syntax is especially harmful for that code and makes it harder to read =
(once you get a bit used to ~>, it will be easy to read, really).

>> Just because, I'll say it, the less symbols you have to read the =
faster
>> you'll read it. To some extent, of course, a counter-example being =
Perl
>> language. But I don't think that we are even close to it.
>=20
> Yes, in this instance we are. And that's not a good thing.

As said, there is a fine line between abusing the syntax and using it in =
horribly inapt scenarios, or using it where it really helps.

>> Your point about capturing too much if you have too much in the =
global
>> scope is legit but in this case I'd say two things: you can still use
>> long closure syntax, and second you have a problem with global scope =
not
>> short closures.
>=20
> No, I don't have a problem with global scope - this proposal has a
> problem with any scope that contains many variables. Actually, =
virtually
> every scope contains more variables than closures need. Without this
> capture there is no problem.
>=20
>> You see the main use case for anon. functions is when you need a
>> *lightweight* callback for something. If it were a fat function I'd
>=20
> And capturing whole scope makes it anything but lightweight, =
especially
> if you have big scope.

=46rom the RFC:
> all variables used in the body of the anonymous function will =
automatically be bound to the anonymous function closure from the =
defining scope

The implementation is not capturing all the variables from the outer =
scope, but strictly only these accessed by the variables in the Closure =
itself. Hence that shouldn't be much of an issue.

>> probably make it named and write tests for it. But when it's a small
>> function, often consisting from only one expression it kinda bothers =
me
>> when the body of this function takes less keystrokes than 'function' =
and
>> 'return' keywords...
>=20
> If keystrokes are a problem, there are lots of solutions - like IDEs
> that allow to define macros. Saving keystrokes at the cost of
> readability never was a principle in PHP, and I don't think we should
> start now.

Agree, don't start with keystrokes here. They're maybe a nice =
side-effect, but that's really not a thing to argue about.
It's really not the goal of the RFC to decrease readability. That'd be =
insane.

> --=20
> Stas Malyshev
> smalyshev@gmail.com


Thanks,
Bob=