some generator issues

[Brendan Eich]

On Apr 23, 2007, at 9:39 AM, Yuh-Ruey Chen wrote:

> Replacing |this| is not what I'm suggesting - in fact, I rejected  
> it for
> the reason you give. |this| within the generator function is left
> untouched - it's not replaced with anything.

Ok, good to agree.

> The generator-iterator is
> accessed within the generator function via arguments.generator.

This is still a bit awkward for the reason given by Neil, and with  
rest parameters, we are trying to avoid arguments being a commonly  
used object (so that some day it might become deprecate-able -- it's  
far from that now).

> Then I
> proposed that next() and send() are bound class methods rather than
> unbound prototype methods.

Right, and I pointed out how they're uselessly re-bindable (to any  
object), but that if re-bound (I mean |this| binding here) to a non- 
generator-iterator object, you'll get a type error trying to call them.

> I'm not exactly sure how class methods are
> implemented, but in ES3, this is practically equivalent to:
>
> // constructor for generator-iterators
> function Generator(...) {
>     ...
>     var self = this;
>     this.next = function() { return Generator.prototype.next.call 
> (self); };
>     this.send = function(x) { return Generator.prototype.send.call 
> (self,
> x); };
>     ...
> }
>
> ...with the added benefit that Generator.prototype.send/next can still
> be overwritten meaningfully.

That's not always a benefit. See https://bugzilla.mozilla.org/ 
show_bug.cgi?id=354750.

> But as I said before, it seems odd that
> only next() and send() are special, or that Generator (and possibly  
> its
> counterpart, Iterator) is special with respect to the builtin
> constructors already in ES3.

Sorry, not sure what you mean here. There is no Iterator nominal type  
proposed for ES4. There's no Generator or Iterator in ES3.

Locking up methods against AOP-style overriding via mutable prototype  
bindings is sometimes the right thing for integrity, which is a  
security property.

> In any case, I've been experimenting with Python lately to see if
> there's some convenient solution for the intended use case (async  
> calls
> and returns), since Python's generator functions also lack a way to
> access their "parent" generator-iterators. One library I've been  
> looking
> at is the Twisted framework, or rather it's Deferred component. It's
> solution to this issue is an inlineCallbacks function intended to  
> wrap a
> generator function within some sort of generator manager:
> http://twistedmatrix.com/documents/current/api/ 
> twisted.internet.defer.html#inlineCallbacks.

Yes, this is familiar too from MochiKit, which was inspired by  
Twisted. But the question you raise remains: should there be a more  
convenient, primitive way to denote the current generator-iterator  
from within its generator function?

/be