Hey, thanks for your feedback, but I think you'd got one or two things wrong…
> Am 01.09.2015 um 02:24 schrieb Stanislav Malyshev <smalys...@gmail.com>:
>
> Hi!
>
>> 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
>
> Shrtr dsnt lwys mks thngs esr 2 rd.
> Sometimes it's quite the opposite.
>
>> It would be much easier to read and write with the short syntax:
>>
>> $collection = array_filter(array_map((Type $el) ~> $el->getStuff(),
>> $collection));
>
> 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.
>
> 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.
>
> 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.
>
>> 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
>
> And capturing whole scope makes it anything but lightweight, especially
> if you have big scope.
From 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...
>
> 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.
> --
> Stas Malyshev
> smalys...@gmail.com
Thanks,
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
