- From: Francois REMY <francois.remy.dev@outlook.com>
- Date: Sun, 18 Aug 2013 21:32:23 -0700
- 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