Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60780
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4FCF2F09.8050904@hoa-project.net>
References: <CAF+90c_47HtYHnMztUUb7Gd5_gKhpJYJN=G-KJFSmSt_=w2+Lw@mail.gmail.com>
	<4FCF2F09.8050904@hoa-project.net>
Date: Fri, 8 Jun 2012 13:16:11 +0200
Message-ID: <CAF+90c9vaK=mGG=hwbbnVV7bwQp+_81nedUJqeLowenCLoqOXQ@mail.gmail.com>
To: ivan.enderlin@hoa-project.net
Cc: internals@lists.php.net
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Generators in PHP
From: nikita.ppv@googlemail.com (Nikita Popov)

On Wed, Jun 6, 2012 at 12:20 PM, Ivan Enderlin @ Hoa
<ivan.enderlin@hoa-project.net> wrote:
> In addition to Gustavo's remarks, I wonder how the GC would collect a
> Generator object that is not use anymore (especially with a referenced
> yield). Does it fit to the current CG strategy or do we need an extra
> strategy? I would notice that the =93Yield by reference=94 section does n=
ot
> exist but you have targeted it).
I added a new section which answers the question at least partially:
https://wiki.php.net/rfc/generators#closing_a_generator
If you don't need the generator object anymore you can either
explicitly ->close() it or wait until all references to it are removed
(typically when leaving the scope of the calling function). When the
generator is closed it releases all used resources, including the
suspended execution context and the currently yielded value. Whether
or not the value is yielded by reference shouldn't make a difference.
So, yes, the current GC strategy works well for generators too :)

> Moreover, I wonder how a =93recursive yield=94 would act (something like =
=93public
> function *f ( =85 ) { =85 yield $this->f(=85); =85 }=94). It is possible?=
 Is it
> anticipated?
Your particular code would simply yield a generator object (as that's
what $this->f(=85) returns).

If instead you wanted to yield all values from that object you could
wrap it in a foreach loop:

function *f() {
    // ...
    foreach ($this->f() as $value) {
        yield $value;
    }
    // ...
}

What this doesn't yet properly cover is the use of generators as
cofunctions. In this case it is desirable that ->send() calls are also
propagated (same applies to ->close() and the not yet implemented
->throw()).

To cover all those use-cases you'd have to come up with a rather big
and ugly block of code (you can find a Python same implementation in
http://www.python.org/dev/peps/pep-0380/#formal-semantics).

Thus it is clear that another expression is required which allows you
to delegate execution to another generator/cofunction. In Python this
is "yield from", in JavaScript "yield*".

A tree implementation using it could look like this:

class Tree implements IteratorAggregate {
    protected $value, $left, $right;

    public function __construct($value, Tree $left =3D null, Tree $right =
=3D null) {
        $this->value =3D $value;
        $this->left =3D $left;
        $this->right =3D $right;
    }

    function *getIterator() {
        if ($this->left) yield* $this->left;
        yield $this->value;
        if ($this->right) yield* $this->right;
    }
}

As you can see the iterator implementation is dead simple.

(Note though that the yield* expression described above isn't yet
implemented, but I plan to implement it.)

Nikita