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

(cced the Extensible Web CG since prefixing issues have been discussed extensively there)

± So, recently, there have been some collisions between methods added by a
± library and ES6 planned Array#find, maybe endangering the addition of
± Array#find to the platform. The details are unimportant; what is important is
± that that'll happen again.
± 
± I'm coming as a (totally illegitimate) web developer community
± representative to ask if we can agree on some rules that would both enable
± developers to create libraries and extend built-ins (because
± myArray.newMethod() or "some string".whatever() or
± document.querySelectorAll(s).map are convenient) while not preventing
± future growth of platform APIs.

I agree with you on the premises.


± The reason is that currently, each library is trying over and over to solve the
± namespacing problem. Some do fine. Others fail. We need a platform-wide
± principle. We need commitment from web browsers and specs that some
± parts of the namespaces are free for library authors to use freely.

That may sometimes not work. The issue that it solves is that some modern code will never fail on a website because the native function he expects has been replaced by some other one. The issue it doesn't solve is that two libraries could want to use the same function name with different purposes/implementations.


± * unique strings [1] (eventually unique symbols) could be used to guarantee
± avoiding collisions. The simplest form of cooperation between a library and
± client code I have found is at
± https://gist.github.com/DavidBruant/6256883 and I'm not sure it's
± satisfactory I believe that the forced bracket notation in client code and the
± sharing through globals (for things that are supposed to be already reachable
± from the global!) is the reason why web devs haven't come up with this
± solution themselves.

The main issue there is the global variables. We only partly solve the issue because we've to expose our key-related stuff, and we've to expose it in a way that's not particularly elegant.

However, with the raise of modules, exporting keys will become much easier. Any code can simply import a module, and the module will bring with him the key names. The user code can safely choose to use direct or namespaced import if he believes the import could conflict with another library. 

The only thing that sucks right now is that it's hard to provide a good intellisense (autocompletion) for those keys because they do not have a canonical name. Maybe we should define a way for unique strings to be exposed properly (alternatively we can ask the IDE to be smart an guess the keynames currently accessible by walking through imported modules).

The second thing I dislike terribly is that the current key-model breaks your mental model, because you've to care whether you are using a "normal" property (in which case you have to type a dot) or a "custom" property (in which case you have to type a bracket). 

I think the language would be in a much better shape to deal with the naming issues if it did support "obj.[key]" as an alias to "obj[key]". Some languages like F# allow that and I find it very convenient. It helps me get straight to the point. SweetJS, TypeScript or my IDE could help me with that during the transition, but this will only be implemented in a sufficient amount of IDEs if ecmascript adds it to its future version roadmap.




± * The global object is free for everyone (spec or webdevs) to write on it.
± Creating a global property should never fail for JS code.

Defintely agree with you, but again this only solve part of the problem. If I library overwrite some native function, you can't use it on your website after that (and some other scripts may do the mistake to confuse them).


± * Web browsers commit to never define methods or attributes (using
± WebIDL terminology, but applies equally to the ECMA 262 spec) that starts
± with "_" to built-ins

It should clearly have been the case forever. I will never hate __proto__ enough given what it merits...
 
± * Web developers commit to never extend a built-in unless the property
± name starts with '_'.

I cannot agree on that. Firstly, using an underscore is ugly. Secondly, it doesn’t solve cross-library prefixing. Anf finally, extending may have multiple meanings here, depending on which you may or may not want to allow such extensions.

If an extension is a *true* polyfill, in the sense it polyfills a relatively stable spec that has been shipping in at least a browser and that it does his job correctly, I've no issue reusing the real name for the polyfill.

If the extension is a prollyfill (ie: "I wish browsers had it") then they should definitely use a unique string/symbol. There's simply no way a speculative polyfill can deal with a browser or another library shipping an implementation of his stuff, so we must be sure conflicts simply do not happen.



Thoughts?

Received on Sunday, 18 August 2013 03:54:56 UTC