Re: RFC Draft: Comprehensions
| From: | Alexandru Pătrănescu | Date: | Mon, 11 Mar 2019 04:07:38 +0000 |
| Subject: | Re: RFC Draft: Comprehensions | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-104643@lists.php.net to get a copy of this message | ||
Hi Larry,
I'm still digesting the syntax and people have already said about it the
most important things.
I mostly wanted to mention that I think comprehensions should return
\Iterator instead of \Generator. There is nothing that stopped us from
having lazy iterators, even before generators were available.
IMO, all points in *Why generators?* section are valid with \Iterator and
you also noted that send() method is kind of useless.
Just to make it clear, I agree that behind the scene it can use the same
logic of a \Generator but I think userland type should be \Iterator.
For example, if we look at this two important functions widely used for
processing lazy/infinite iterators, the return type is \Iterator
function map(callable $function, iterable $iterable): \Iterator
https://github.com/nikic/iter/blob/master/src/iter.php#L79
function filter(callable $predicate, iterable $iterable): \Iterator
https://github.com/nikic/iter/blob/master/src/iter.php#L203
Regards,
Alex
On Sun, Mar 10, 2019 at 11:45 PM Larry Garfield <larry@garfieldtech.com>
wrote:
> 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
>
> Sara Golemon has written a preliminary patch that is partially complete
> (see the RFC link for details, it's impressively simple), but unfortunately
> doesn't have the bandwidth to complete it at this time. I am therefore
> looking for collaborators with more knowledge of internals than I (which is
> almost everyone) to help finish it up.
>
> The syntax proposed is also subject to revision if a terser but still
> lexer-friendly alternative can be proposed.
>
> At the moment I'm not calling this Proposed yet, as I don't feel
> comfortable doing so until someone else is on board to finish coding it.
> That said, if someone wants to weigh in on the concept for now (hopefully
> supportively) that's also fine.
>
> Anyone excited enough to help finish the job?
>
> (This is my first RFC collaboration, so if you're going to smack me for
> goofing something please be gentle about it.)
>
> --
> Larry Garfield
> larry@garfieldtech.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>