Design principles for extending ES object abstractions

David Herman dherman at
Fri Jul 8 17:07:49 PDT 2011

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

Like most principles, I think these are reasonable to keep in mind but not absolute. In particular, I see no sensible way to claim that generators can be "done imperatively" in the old language. Arguing that you can "do generators" with some new Function constructor is falling into the Turing tarpit: Function is just an eval in sheep's clothing. You can do *anything* Harmony can do in ES5 if you have access to the Harmony eval, or if you write a Harmony interpreter, or if you do an RPC to another computer that has a Harmony evaluator installed on it, or...

But hey -- generators are awesome! They're Harmonious, and web developers deserve them. I don't care if they fit into some platonic ideal of ES5-Harmony parity.

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

I agree, but I think this could be done with a minimum of global namespace pollution. For example, let's say we only make the Harmony SystemLoader available to legacy code. That would be enough for ES5 code to:

- get access to new standard Harmony modules, such as "@name"
- get access to a Harmony evaluator via SystemLoader.eval
- get access to user-created Harmony modules

And it wouldn't require overloading the Object constructor -- from here until eternity -- with a bunch of short-term backwards-compatibility cruft.

But still, I agree with Allen that we should strive where possible to shoot for the goal of making dynamic/reflective analogs of static constructs. For example, Luke has mentioned that he'd like an ability to dynamically construct module instance objects. I think this is a good goal. But not so much for legacy code to have access to it, as for the ability for meta-level code to dynamically interact with base-level code. For example (using totally made-up API's, please don't bikeshed the names):

    childLoader = parentLoader.create(....);
    childLoader.registerModule("m", childLoader.buildModule({
        x: 42,
        f: function() { ... }


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

More information about the es-discuss mailing list