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. > 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. > 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. > 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. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
