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.
For me, the issue is that ES engines tend to implement new
language versions gradually (currently, still not everyone
implementing ES5, yet some providing experimental features
beyond ES5). That practice is good (gets useful features out
there faster) and it matches the ES proposal wiki organization
but JS language versioning on the web is not yet as modular
(see the other thread for generators example, url below).
I tend to think about language feature pragmas as a solution,
but that is because I've seen that approach work in practice
elsewhere. The idea of using ES/next modules to manage
dependencies on language features is new, so I'm not sure
it would work as well. It depends on two assumptions:
- ES/next modules need to be the first ES/next feature to
be implemented, so that the other features can be
versioned using modules;
that is, Firefox generators would only be available
through modular versioning after adding modules
- dependencies on language.feature modules have to
be treated specially, to get useful error messages:
usually, module dependencies are looked into after
parsing, which is too late to complain about features
that are not yet supported (I don't know how this
interacts with transitive dependencies - might render
the idea unworkable..)
In other words, it is an ad-hoc idea about using module
dependencies as language version pragmas, without having
to add pragma syntax. It does have the advantage that
modules have dependency management and early errors
as part of their feature set already.
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".
Thanks. My own single-message thread is here:
feature-based and compartment-based language versioning
https://mail.mozilla.org/pipermail/es-discuss/2011-July/015755.html
From some of the messages in your thread it seems you
have found yet another variation on mixing versions: using
ES/next functionality while sticking to ES5 syntax (imperative
access to some syntax-based declarative ES/next features).
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"?
1. so that we can write code that wants to be ES/next,
and get early failures with good error messages if that
code tries to load on an engine that does not implement
all ES/next features the code depends on.
(not "parse error at 'yield'" but "this engine does not
implement generators yet, sorry")
2. so that we can write code that only depends on some
ES/next features, and enable engines to figure out
early if they are able to load and run this code, based
on their partially implemented ES/next feature set.
(if code depends only on generators, current Firefox
may be able to run it, but we can't specify a dependency
on only that feature)
3. so that we can selectively enable experimental language
features, which will continue to be implemented prior to
standardization, even after ES/next.
(if code depends on generators, but should not be used in
combination with some of the other experimental features
in Firefox, we cannot specify such a selection at the moment)
4. So that coders can document their language feature
dependencies in their source code (as page scripting is
replaced by JS applications, and script files are replaced
by modules).
Claus
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
