StopIteration, ForwardToTarget, ... & symbols

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Nov 26 18:18:43 PST 2012


On Nov 26, 2012, at 5:27 PM, Brendan Eich wrote:

> David Bruant wrote:
>> Le 26/11/2012 22:11, Brendan Eich a écrit :
>>> Herby Vojčík wrote:
>>>> Hi,
>>>> 
>>>> shouldn't StopIteration, ForwardToTarget from "Notification proxies" thread and similar ones be rather well-known unique symbols (like @iterator), now that we have them, instead of well-known globals? \
>>> 
>>> Why?
>>> 
>>> Let's separate the naming and unique identity concerns. Objects have unique identity, so do symbols. But if a unique identity is required without being a property key, then an object is the right answer, not a symbol.
>> I'm not sure not being a property key is that big of a constraint, so I would say that objects and symbols are both valid equally valid.
> 
> Perhaps not, but it's odd to make a symbol just for (e.g.) immutability with no properties or [[Prototype]]. For realm-independence is more interesting. More below, on your good point I had forgotten momentarily in replying to Allen a minute ago.
> 
>>> I think this applies to StopIteration.
>> It is suggested on the strawman that StopIteration be a constructor [1] and I support this idea for StopIteration because an iterator may have different reasons to stop and building instances with a message (or any property) attached.
> 
> Yes, indeed, and StopIteration as constructor is used implicitly when a generator function returns a value. This makes the case for object not symbol. isStopIteration copes with realm-dependence.
> 

There would be another way to accomplish supporting generator return values that doesn't require dynamically constructing new StopIteration instances and avoids all Realm issues:  Capture the return value in the generator instance when it enters the "closed" state and then throw the single immutable StopIteration object (could be a Symbol).  A client of the generator instance that catches StopIteration and expects a return value can directly query the generator instance (via a property access) to get that return value.  It accomplishes the same thing but doesn't require multiple StopIteration instances, an extract allocation on generator returns, a call to isStopIteration to test, etc.


Allen


More information about the es-discuss mailing list