On Jul 11, 2011, at 10:38 PM, Luke Hoban wrote: > >>>>If so, it seems safe to consider generators as sugar for producing > >>>>objects whose visible behavior could have been built independently. And > >>>>interoperation appears to work cleanly in both directions using these > >>>>objects. > > >>You're talking about interoperation in the "old script calls new generator" > >>sense. That's using generators from old script, *not* implementing them > >>using imperative API *in old script*. > > I’m actually interested in both directions of interoperation. For example, > future-jQuery might want to expose objects that are iterable and can be > consumed in generators when used in ES6 syntax, but without itself opting > into ES6. It could presumably do so by implementing the required state > machines by hand and exposing next/send/throw/close.
Implementing a structural or duck-typed protocol such as the iteration protocol, or the generator interface, with "legacy" (I kid!) JS, meaning no new syntax, is absolutely part of the design. We've supported that since JS1.7 (2006). That's not the same as somehow getting an API callable from old script, let's call it doYield(e), that captures the shallow continuation and returns e to the sender or .next caller. Yet such an API is what the Principle, with full capital P if not all-caps, implies. That's where I draw the line. /be
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
