> >>>> 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 ES.next 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() { ... }
});
Dave
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
