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
Object.evalInHarmony("...")
then we're done.
> That’s the value-add of opting-in to the ES.next 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 ES.next
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 ES.next, 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 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.
That's a good point. If we expose just one property, say
Object.ModuleLoader
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
(http://answers.yahoo.com/question/index?qid=20090513192850AAGmPAH). And we
need some good taste and judgment in knowing when to ease off on the
Principle-mongering.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
