On Jul 11, 2011, at 12:46 PM, Allen Wirfs-Brock wrote:
> I think there is a (usually unstated) desire to also test for ES.next
> features that may also start to show up as extensions to "ES5" level
> implementations. For example, generators in Firefox. You can't depend upon
> modules in such situations.
The thread with subject "Design principles for extending ES object
abstractions" got into this, and I *thikn* (I can't be sure because he hasn't
replied yet) Luke Hoban, Dave Herman, and I were kinda/sorta agreeing that the
"old scripts" (ES5 and below) need just one API entry point: SystemLoader as a
global property (I misspelled it Object.ModuleLoader in my reply to Luke).
Once old script has object-detected its way to joy via SystemLoader, it can
load built-in ES6+ libraries such as "@name" and "@iter".
The API for module detection is under development, but it would allow both
synchronous testing for a built-in or already-loaded MRL, and an async form for
loading from an MRL over the 'net.
Given this (forgive the lack of complete specs, but it's enough, I claim), why
do we need anything more for future-friendly "feature detection"?
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
