using Private name objects for declarative property definition.

Claus Reinke claus.reinke at talk21.com
Mon Jul 11 11:50:35 PDT 2011


>> 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
 


More information about the es-discuss mailing list