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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss