Hi, 2015-09-30 8:10 GMT-03:00 Rowan Collins <rowan.coll...@gmail.com>: > Levi Morrison wrote on 29/09/2015 22:55: >>> >>> When you choose the function($x) ~> $x * 2 (or with ==> or => >>> >operator), you end up saving around 5 or 6 characters from the "long >>> >declaration", ending up with "not-so-short closures" instead. You save >>> >a little bit more if you have the implicit "use", but that's one thing >>> >people are torn about, by looking at the discussion about the RFC, but >>> >I think it's too long, for "short closures". >> >> Reading over the list I don't think people "are torn about" it. There >> are some detractors, sure, but there seem to be more detractors about >> symbol choice (~) and lack of type declarations. > > > On a quick glance through the list I gathered the following names expressing > disapproval of the automatic capture (apologies if I've misrepresented > anyone's opinion here, it was a very quick skim through!): > > Dmitry > Rasmus > Peter Petermann > Bishop Bettini > Stas > Ferenc > Thomas Punt > > Plus a couple of other people on the fence on the issue (as am I): > Marco Pivetta: "I am still conflicted..." > Arne Blankerts: "I can see the benefit ... but consider it a break of > concepts (habit?) from everywhere else in PHP." > > > That seems like a significant proportion of the people actively > participating in the thread to me; as mentioned elsewhere, there are more > people who've voted no than have expressed their reasons on the list, and > it's a mug's game to guess which factors influence whom. Also, remember that > the votes on RFCs are intended to confirm consensus, not replace it - the > idea is not to win over just enough people to "win", so it's not necessarily > about numbers. > > That's not to say that automatic capture is an absolute blocker, but I think > "the internals community is divided on it" is a reasonable summary. >
That's the part I couldn't comprehend in the discussion. Auto import is basically the most interesting reason to have short closures on PHP. Apart from syntax sugar which, could be nice but, on it's own wouldn't be as important to most people. > Regards, > -- > Rowan Collins > [IMSoP] I abstained from voting on Bob's proposal because of the syntax choice ~> and because of the lack of types support. With that said, I think Levi's proposal is more complete without hurting our current expectations regarding deterministic parsing. Levi's proposal also open doors for a short method declaration as "fn" could become interchangeable with "function" (if we choose to propose the "fn" prefix). I still have a personal preference for the '==>' because it *looks* less ambiguous on the array edge case '[fn($x) => $x * 2]' vs '[fn($x) ==> $x * 2]', and of course because it is more efficient to grep. But that preference wouldn't be enough for me to reject the RFC with '=>'. Ty, Marcio -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
