>>>> 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. 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. 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. >>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. 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. >>>> ES.next 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. 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 :).
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
