W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

RE: Non-agression pact for the JS runtime namespace territory

From: François REMY <francois.remy.dev@outlook.com>
Date: Sun, 18 Aug 2013 11:40:26 -0700
Message-ID: <DUB406-EAS54E52763DD5E8F65E7DA99A5410@phx.gbl>
To: "'David Bruant'" <bruant.d@gmail.com>
CC: <public-script-coord@w3.org>, <public-nextweb@w3.org>
± >> For a prollyfill, what's the benefit of a unique string over a prefixed
± property?
± > Dependencies. Library A relies on prollyfill A and Library B relies on
± > prollyfill B, both of which represent different versions of the spec
± > but have some conflicts. If they use a simple prefix
± No one prevents them to sub-namespace after the prefix. How is this
± problem solved today? Just apply the same solution but with an additional
± prefix.

The fact is, they don't use lib-prefixes today. Asking them to double-prefix when they do not even single-prefix now seems unlikely to succeed, even if we could agree on some set of conventions. 


The main reasons is Loss of clarity. 

    querySelectorAll(...).map(...)

is way better than

    querySelectorAll(...).myJQueryMap(...)

and also easier to write.


However, with symbols, you can get to something quite readable:

    // provider
    module TotoLib {
        export const map = Symbol("TotoLib.map");
        HTMLCollection.prototype.[map] = function map(f) { ... }
    }

    // client
    module MyCode {
        import TotoLib
        querySelectorAll(...).[map](...)
    }

Also, if you have conflicts:

    // provider
    module TotoLib {
        export const map = Symbol("TotoLib.map");
        HTMLCollection.prototype.[map] = function map(f) { ... }
    }
    
    // provider
    module TataLib {
        export const map = Symbol("TataLib.map");
        HTMLCollection.prototype.[map] = function map(f) { ... }
    }
    
    // client
    module MyCode {
        import TotoLib;
        import TataLib as TataLib; // direct import would fail because conts cannot be overriden
        querySelectorAll(...).[map](...)
        querySeletctorAll(...).[TataLib.map}(...)
    }



Now if TataLib is an extension of TotoLib and wants to actually replace TotoLib implementation, it can do either

    import TotoLib; export map;
    HTMLCollection.prototype.[map] = function map(f) { ... }
    // reuse the same map thing, and loads TotoLib if not already done

Or if he do not want to load TotoLib if it hasn't been loaded by the current page, but still want to cooperate with him if he was, I propose

    export const map = Symbol("TotoLib.map")
    HTMLCollection.prototype.[map] = function map(f) { ... }
    // tentatively reuse the same map thing by identifier

Where Symbol would return the same symbol every time it's called with a given identifier (ie: acts like a symbol weak map)
Received on Sunday, 18 August 2013 18:41:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC