Design principles for extending ES object abstractions

Brendan Eich brendan at
Mon Jul 11 22:26:13 PDT 2011

On Jul 11, 2011, at 10:00 PM, Luke Hoban wrote:

> So I was wrong about iterators being the general interoperable runtime mechanism, but next/send/throw/close objects appear to be fully iterable and consumable in generators.  Is that right?

That's right, there is no nominal type test.

> 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*.

The contested principle is Anything that can be done declaratively can also be done imperatively, using ES5 syntax.

You can't write a yield expression using an imperative API. Yielding is something "that can be done" (whether declaratively or by expression syntax, let's not quibble). So the principle overreaches.

As for someone using "legacy" to describe ES5-ish JS (JS of today), don't take it to heart. JS is JS, the new version is just that. We survived ES1/2 to ES3. We'll survive the next turn.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list