Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104678 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 91152 invoked from network); 12 Mar 2019 18:37:20 -0000 Received: from unknown (HELO more.superhosting.bg) (91.196.125.214) by pb1.pair.com with SMTP; 12 Mar 2019 18:37:20 -0000 Received: from [94.156.78.222] (port=58066 helo=[192.168.20.137]) by more.superhosting.bg with esmtpa (Exim 4.91) (envelope-from ) id 1h3jJ8-000AcX-K1; Tue, 12 Mar 2019 17:27:13 +0200 To: Chase Peeler , Kalle Sommer Nielsen Cc: Larry Garfield , Internals References: Message-ID: <0297da77-269d-b364-b7f7-a0aa8578b640@hristov.com> Date: Tue, 12 Mar 2019 17:27:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - more.superhosting.bg X-AntiAbuse: Original Domain - lists.php.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hristov.com X-Get-Message-Sender-Via: more.superhosting.bg: authenticated_id: php@hristov.com X-Authenticated-Sender: more.superhosting.bg: php@hristov.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [PHP-DEV] RFC Draft: Comprehensions From: php@hristov.com (Andrey Hristov) 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 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 >