Hi internals The reason multi-line short closures are so valued by userland devs is because they are shorter to write and prettier to read. While some of us might not agree on the definition of "prettier to read", it was one of the key arguments for adding short closures in the first place:
> Anonymous functions in PHP can be quite verbose, even when they only perform > a simple operation. Partly this is due to a large amount of syntactic > boilerplate, and partly due to the need to manually import used variables. > This makes code using simple closures hard to read and understand. This RFC > proposes a more concise syntax for this pattern. [1] > We can have the discussion again on whether we like short closures or not, but it turned out most of internals _and_ userland devs do — based on the vote count in the sigle line RFC and the reaction on Nuno's PR, as well as my experience from an OSS maintainer point of view. Furthermore, the `use(*)` syntax misses the point of this proposal: it's not about being able to use all variables from the outer scope, it's about a clean syntax that's as short as possible — even when you personally disagree that it is. I've made the same argument before on this list: it's clear that the PHP community _wants_ these changes: named arguments, property promotions, short closures, … these are all features that aren't _necessary_, still they are great features of a modern-day language. I also want to quote from Larry Garfields book on thinking functionally in PHP [2], to demonstrate the signicant impact short closures already had today: > “Combined with PHP’s overall clunky syntax for doing functional-esque code, I > generally didn’t go further than “pure functions are your friend,” either in > my own code or what I explained to others. > > That is, until PHP 7.4. > > PHP 7.4’s introduction of short lambdas is, as we’ll see in this book, a > game-changer. While it doesn’t make anything new possible, it makes a lot of > things suddenly practical. That makes all the difference, so I decided it was > time to buckle down and really dig into functional programming.” Larry continues to write a whole book about functional programming in PHP, and short closures play a significant role. So I hope to see more input on Nuno's PR from a techinical point of view: what's missing, what's needed to get this to the RFC phase, … and not only discussions about what syntax we like or not, or whether there are other ways to solve the same problem. Please provide Nuno with actionable feedback. Kind regards Brent [1] https://wiki.php.net/rfc/arrow_functions_v2 <https://wiki.php.net/rfc/arrow_functions_v2> [2] https://leanpub.com/thinking-functionally-in-php <https://leanpub.com/thinking-functionally-in-php> > On 5 Oct 2020, at 12:39, Andreas Leathley <a.leath...@gmx.net> wrote: > > On 05.10.20 12:15, Deleu wrote: >> To me that seems like a great argument in favour of the proposal. If you'll >> want all variables to be imported (which in this case makes completely >> sense), then `fn() {}` or `fn() => {}` is much less verbose and inline with >> the mentality to reach for short closures. We reach for short closures to >> avoid `use()` and convey that the outer process is intertwined with the >> inner process. `fn()` allows to strengthen the concept that there's no real >> separation between running SQL stuff in a `callable` that wraps a database >> transaction. > > Not necessarily: the arrow functions were specifically implemented for > very short anonymous functions with a return value. Making them more and > more like the existing "function" syntax would lead to having two > different ways of defining anonymous functions that mainly differentiate > themselves by including the parent scope by default or not. > > I like the "function () use (*)" suggestion because it is explicit and > opt-in. A shorter syntax like "fn () {}" is less clear, and it could > lead to many people always using fn just because it is faster to write > (and less to think about), which then could lead to unintended side > effects because variables are being copied from the parent scope each > time. When you see a usage of "fn () {}" while reading code you would > not know if the person used it because it was faster to write, or if the > parent scope variables are really needed. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php >
