On Mar 7, 2013, at 11:05 AM, Andreas Rossberg wrote: > On 7 March 2013 18:30, Allen Wirfs-Brock <[email protected]> wrote: >> On Mar 7, 2013, at 7:37 AM, Andreas Rossberg wrote: >>> >>> 1) Are the methods of a generator object installed as frozen >>> properties? (I hope so, otherwise it would be more difficult to >>> aggressively optimise generators.) >> >> We discussed the factoring of the generator objects at the Nov 27 meeting. >> https://github.com/rwldrn/tc39-notes/tree/master/es6/2012-11 there is a >> sketch of the hierarchy we agreed to in in the notes >> https://dl.dropbox.com/u/3531958/tc39/generator-diagram-1.jpg >> >> TThe design I presented at the meeting is very close to that final one, >> answers this question, and is easier to read: >> http://wiki.ecmascript.org/doku.php?id=meetings:proposed_generator_class_hierarcy_nov_2013.png > > Ah, thanks. It seems that I missed that part of the meeting. I'll have a look. >
I created a more readable class hierarchy diagram based on the above photo from the Nov. meeting. This is what I'm using as my guide for putting generators into the spec. draft. The diagram is at http://wiki.ecmascript.org/lib/exe/fetch.php?cache=cache&media=harmony:es6_generator_object_model_3-29-13.png The most significant change from the meeting (and it really wasn't explicit on the whiteboard) is that generator prototypes don't have a "constructor" property that links back to its generator function instance. In other words, you can't say: function * ofCollection() {for (i of collection) yield i}; var itr1 = ofCollection(); var itr2 = iter1.constructor(); //TypeError Allowing such constructor access seems like an unnecessary (and possibly undesireable) capability when you just passing generator instances around to be used as iterators. Anybody disagree? itr1 instanceof ofCollection still works (subject to the usual instanceof caveats) Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
