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

> The second issue is that method names have to be unique.

> Nobody's is going to say that all javascript functions should be defined
elsewhere than on the
prototype of the objects themselves

DOM classes like `HTMLElement` could be extended with unique symbols that
have no namespace collisions assuming the syntax for invoking symbols as
methods isn't too tedious.

However when talking about ES5 and implementing new DOM methods like
`HTMLElement.append` there is not much choice other then to say that
library authors who extended `HTMLElement` will probably need to change
their code.

This is less of a problem for ES6 as they can use modules & symbols / names
for functionality.

On Sun, Aug 18, 2013 at 9:32 PM, Francois REMY <
francois.remy.dev@outlook.com> wrote:

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