some generator issues

[Brendan Eich]

On May 8, 2007, at 6:09 PM, Yuh-Ruey Chen wrote:

> Lars T Hansen wrote:
>>
>>   this generator
>>
>> names the generator object as the proposed arguments.generator would.
>>
>> --lars
>>
>
> I like it. What's the operator precedence?

I suggested primary, so one can write |this function.length| instead  
of having to parenthesize, or unary, by analogy to delete, void, etc.  
(so parentheses are required for a . or similar member operator).

> I wonder if this can be extended to iterators in general. Since
> generator functions are essentially sugar (albeit really awesome  
> sugar +
> send() + close()) for iterators, |this generator| could be generalized
> to |this iterator|. Although generator-iterators are different from
> normal iterators, they are iterators nonetheless. I can't think of any
> use cases of the top of my head, and I'm not sure how it would be  
> done,
> considering that iterators are a protocol, not some class (i.e. I'm  
> not
> sure how ES can determine |this iterator| when the user calls
> iter.next() for a user-defined iterator).

You must mean in a function implementing the next property of  
IteratorType, but then it's easy to find the iterator via |this|. On  
the other hand, the generator's |this| may be bound arbitrarily at  
the time the generator function is called (e.g. to the global object,  
or to some class instance if the generator function is a method). So  
we're really talking about a case that's special to generators here.

/be