some generator issues
brendan at mozilla.org
Mon Apr 23 08:39:33 PDT 2007
On Apr 22, 2007, at 9:04 PM, Yuh-Ruey Chen wrote:
> Alternatively, we could make gen.next() and gen.send() special in that
> they are already prebound to gen (e.g. gen.send.call(anotherGen) still
> results in gen.send()).
This is a possibility, but it would change the |this| binding inside
the generator function from its initial value, captured when the
generator function was called to create a geneator-iterator.
The JS1.7 native methods for generators (next, send, etc.) throw if
called on the wrong type of |this|, so it's conceivable that ES4
could bind these methods to their generator-iterator and avoid such
type errors. But what you propose above requires re-binding |this| in
the saved execution context for the generator function, which is kept
inside the generator-iterator.
> Personally, I'd rather not do this - pretty much
> all builtin classes have unbound prototype methods rather than bound
> instance methods.
Not all built-in classes have unbound prototype methods, and for good
reason in certain cases. String and Array methods are intentionally
generic, apart from to*String/valueOf -- those throw type errors if
Class methods in ES4 are bound, so extracting a reference to one
forms a binding with the object from which the method ref was
extracted, supplying that object as |this| in subsequent calls via
But the idea for generator next and send that the saved |this|, from
the original activation of the generator function, would be replaced
by the generator-iterator, is interesting. It provides the
convenience Yuh-Ruey is seeking. On the other hand, it overwrites the
|this| captured in the generator call. I think that's a fatal
So still looking for a slick way to propagate the generator-iterator...
More information about the Es4-discuss