Design principles for extending ES object abstractions

Brendan Eich brendan at
Fri Jul 8 17:12:33 PDT 2011

On Jul 8, 2011, at 4:27 PM, Luke Hoban wrote:

> >>>> I agree wholeheartedly with these.  In fact, I’d go further on (2), and say “Anything that can be done declaratively can also be done imperatively, using ES5 syntax”.
> >>The problem here is that some new syntax cannot be faked with old syntax, namely function calls, without quoting code in strings. This is not usable.
> I think it’s fine for the imperative solution to be less usable.

I think we need to agree that eval does not count, as Allen just wrote.

That is, if you'd be happy if old script could call, e..g


then we're done.

>   That’s the value-add of opting-in to the syntax.  And of course some (most) new syntax is just syntax, and the ultimate objects it creates are ones that could have been created using some more complex path.  Those don’t need any library support.  

If eval does count, we're done.

If eval doesn't count, then how pray tell does old code create a generator? Not by building an interpreter in JS.

> When Allen mentioned “imperatively”, I assumed he meant “with a library”.  I’m not actually sure what other interpretation there would be.   So I sort of expected that clarification to “using ES5 syntax” to be a no-op, though I expect it is practically quite important.

The issue is not "with a library", it is whether the only new APIs in must be Object.uglyNameGoesHere, with string arguments for anything that can't be expressed in the old syntax (like yield in a generator).

If we have built-in modules in, we shouldn't have duplicate Object.mumble APIs for them as well (Object is one of those shared-heap objects common to old and new scripts loaded against the same global with the default module loader).

> >>A second problem is that adding API functions means injecting more names into some extant object, probably not the global object. Must all new APIs be Object.createPrivateName and only that? We have already acceptedproposals that use built-in modules instead, so that there is no name pollution.
> I hope, and believe, there are actually not very many new runtime capabilities being added in that don’t already have proposed libraries.  I do think there will need to be some rationalization of the goal to use built-in modules with the reality of ES5-syntax consumers of these libraries.  I’m not sure whether module loaders currently provide a way to do this that would feel accessible.

That's a good point. If we expose just one property, say


then by my reading of the module loaders proposal, ES5 code can do whatever it wants with built-in and other new modules.

Would this be enough for what you're after?

> >>The shared heap imposes some requirements on us, including that old code operating using old syntax with known semantics on a new object must not behave "badly" (details vary). But this does *not* require that all new features, especially those requiring new syntax to be *usable*, must have old, string-based, name-pollusting API functions.
> I agree, the shared heap requirement by itself does not impose this.  But I believe the design principle Allen outlined should lead us to this anyway, and the value we’ll offer to the many millions of existing ‘text/javascript’ developers through object-detectable runtime capability additions is a nice bonus J.

Arguing about "Principles" as if they were ironclad law is a good timekiller, over which TC39 will fall out of Harmony quickly if we do make the mistake of killing too much time.

We need use-cases as well as abstractions like capital-P Principles. We need Aristotle as well as Plato ( And we need some good taste and judgment in knowing when to ease off on the Principle-mongering.


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

More information about the es-discuss mailing list