using Private name objects for declarative property definition.
allen at wirfs-brock.com
Mon Jul 11 12:46:54 PDT 2011
On Jul 11, 2011, at 11:50 AM, Claus Reinke wrote:
>>> 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?
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.
More information about the es-discuss