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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
