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: Francois REMY <francois.remy.dev@outlook.com>
Date: Sun, 18 Aug 2013 21:32:23 -0700
Message-ID: <DUB404-EAS39381B6041E44A74C96DE24A5420@phx.gbl>
To: "'Jake Verbaten'" <raynos2@gmail.com>, "'David Bruant'" <bruant.d@gmail.com>
CC: <public-script-coord@w3.org>
> >  I'm afraid library authors will prefer defining things on
Array.prototype directly so everyone can use them right away.
> 
> Library authors (in userland, i.e. underscore/jquery, not TC39 or WHATWG)
can do that and do whatever they want!
> 
> Rather then restricting what library authors do in user land, if we
restrict the language and the host environment to not add new global
properties and add all new features through the ES6 module system we can
avoid namespace collisions in an easier fashion. (you could even imagine
that host environments use `import Promise from "@promise"` and ECMAScript
uses `import { find, findIndex } from "@@array"` if we want to avoid further
collision in module names)

This technique, even if interesting, cannot possibly work in the case of
JavaScript. Firstly, because we do not only talk about globals but possibly
about any non-primitive class. DOM Classes are defined using a very specific
interface that has been refined to match the JS Prototype-Orientend way of
thinking and allow author extensions on the prototypes. Nobody's is going to
say that all javascript functions should be defined elsewhere than on the
prototype of the objects themselves. 

HTMLElement.prototype.doSomething.call(el,...) exists already now and will
never get any traction because el.doSomething is just much better.

That leaves the possibility of asking JS extensions that do not indend to
polyfill the platform to use your proposed methodology. Actually, I'm a
pretty huge fan of it, because this is how Microsoft managed to give us
dynamic extensions in dotNET. 



But at the same time, I recognize they're unlikely to be my preferred choice
in JavaScript because there's a strong (sic) difference between dotNET and
JavaScript: the typing. In dotNET, the autocompletion can give you extension
methods in context because they know on which type they apply to. I don't
want my intellisence to show me every possible function ever implemented as
an extension by a library, just the one I can actually apply on the current
object. Maybe TypeScript could get that right because of its optional
typing, but most people do not use TypeScript anyway.

The second issue is that method names have to be unique. I cannot use the
same method name for two different things on two different classes, even as
part of the same library, because JavaScript only allows one method
definition per name. All in all, this is not that good, I think.



I continue to prefer the "prefix in ES5, aims to use keys in ES6, make keys
convenient in ES7" approach.
Received on Monday, 19 August 2013 04:32:52 UTC

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