using Private name objects for declarative property definition.

Claus Reinke claus.reinke at
Tue Jul 12 08:17:18 PDT 2011

>> I think there is a (usually unstated) desire to also test for 
>> 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

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


More information about the es-discuss mailing list