Design principles for extending ES object abstractions

Brendan Eich brendan at
Fri Jul 8 16:08:12 PDT 2011

On Jul 8, 2011, at 4:05 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.

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 accepted proposals that use built-in modules instead, so that there is no name pollution.

> will have two syntaxes running on a single runtime, sharing objects across a shared heap.

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.


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

More information about the es-discuss mailing list