Re: RFC Draft: Comprehensions

Hi, the real fun starts when people start to put list comprehension in a list comprehension in a list comprehension. And the result is one-liners that are pretty dense and write once never read. The problem during software development are not the key strokes, it's the time which later has to be invested to understand the code that lack the additional keystrokes. Of course one can learn to understand dense stuff. One can also learn to read German words with a length of 20 and up. It ain't that hard and needs practice. Is it worth when non-compound words also work (hint: German words can be written alternatively with hypens and CamelCaps, which really improves the readability). Best, Andrey On 12.03.19 г. 15:49 ч., Chase Peeler wrote:

On Tue, Mar 12, 2019 at 4:55 AM Kalle Sommer Nielsen <kalle@php.net> wrote:

Hi Den søn. 10. mar. 2019 kl. 23.45 skrev Larry Garfield < larry@garfieldtech.com>:

Hello, peoples. I know it's been discussed once or twice before on the

list, many years ago, but not recently. I therefore feel OK putting forth the following draft proposal for Comprehensions, aka "compact generators", in PHP:

https://wiki.php.net/rfc/comprehensions

While I think believe the RFC has great intentions, I am not a fan by any means to introduce convoluted syntaxes like this into PHP, I think it is rather hard to read vs the gain of saving a few key strokes. I think that both the shorthand closures and this makes PHP code potentially even harder to read and I would prefer we did not add such essential sugar where you need to understand the semantics very well to understand what a piece of foreign code may do, in what order (like the no yield example given). One more thing that kinda "annoys" me / what I base my above statement on is; when reading some of the example is that the code examples given, as in the code inside a Comprehension does not look very PHP-ish besides the $-sigil and I do not like the idea of having "two" syntaxes for PHP where one is only available in a very narrow-, specific context and I feel it would be prone to potential errors. Everything looks weird and "non-phpish" when it's new. OO constructs

weren't PHP-ish at first, because PHP didn't originally support OO. Imagine "foreach" didn't exist in PHP and we were still using while(list($key,$value) = each($arr)) syntax. I agree that some of the examples are a bit hard to read and understand - but that's only because we haven't been exposed to them. This isn't meant as an endorsement of the proposal. I just don't think the fact that it adds something different than what we are used to is a good justification for not supporting it. As a non-voting userland developer, I'm personally ambivalent. They seem cool, and I'm sure I'll use them, but it won't be a big deal if they aren't added.

Another thing that has been mentioned by multiple people now is the for-vs-foreach; If it is a foreach, which you mention in the RFC then it should be so, not for. A little background on where I am coming from here; I think it is great that we look at other languages and technologies when designing PHP and adding more features the language, however while I do believe it is an important point to keep cross language consistency, I do think that consistency with PHP itself is more important, which I believe too, is the reason for the expression for using foreach in this context comes from (not only from my PoV). I was originally going to say I agreed with this position, but, after

thinking about it, I've changed my mind. A "for" loop is just a method of specifying the keys that you are iterating over. Since you aren't specifying the keys inside a comprehension, the traditional "for" loop doesn't really exist. I'd suggest supporting both keywords, though.

-- regards, Kalle Sommer Nielsen kalle@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php --

-- Chase chasepeeler@gmail.com