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 <ka...@php.net> wrote:
Hi
Den søn. 10. mar. 2019 kl. 23.45 skrev Larry Garfield <
la...@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
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
-- Chase
chasepee...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
