How about rest and spread, or de-structuring? We are
going to use non-eval detectability as a ECMAScript
extension design criteria then maybe we do need a less
ad-hoc scheme for feature detection. It wouldn't have
to be all that grand...
Even less grand ones such as the DOM's
(http://www.w3.org/TR/DOM-Level-3-Core/core.html#DOMFeatures)
are failures.
Just noticed this hidden sub-thread, which seems to be related
to my attempt to start a thread on modular versioning. How
about the following attempt at least-grandness?-)
- have a built-in module hierarchy 'language', with submodules
for each new ES/next feature that is implemented in the
current engine (language.destructuring, language.generators, ..)
- code that relies on one of those features can try to import the
language.feature module, and will be rejected early if that
"feature module" isn't available
- there could be collective modules corresponding to language
versions (ES5, JS1.7, ES/next, ..), which behave as if they
imported the language feature modules corresponding to
that language version
- this would suggest that ES/next modules ought to be the
first ES/next feature to be implemented, to support versioned
addition of the remaining ES/next features; but since modules
already need to manage dependencies, there is no need to
replicate that functionality for language features
Makes sense?
Claus
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
