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

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

> If necessary we

If introducing new functionality through modules and non global prototype
properties is not acceptable from a language design point of view then the
language could fix this, the example I was making is that if method syntax
is important for TC39 then we can have similar syntax for functions to work
around the fact you can't import properties onto a global object without
namespace collisions.


On Sun, Aug 18, 2013 at 4:03 PM, David Bruant <bruant.d@gmail.com> wrote:

> Le 19/08/2013 00:44, Jake Verbaten a écrit :
>
>  Why can't we just avoid namespace collisions completely using our module
>> system
>>
>> ```js
>> import { find, findIndex } from "@array";
>>
>> var res = find([1, 2, 3], (n) => return n === 2)
>> ```
>>
> We don't even need modules. Underscore is already this that with success
> [1]
> The "problem" is that people want to do [1,2,3].find( n => n === 2 )
>
>  If necessary we
>>
> we "TC39"?
> a non-standard extension for things like TypeScript?
>
>
>  can have syntax sugar for importing symbol methods instead of functions.
>> Or maybe implement the syntax sugar as some kind of infix function call
>> operator so you can call functions as if they are methods
>>
>> `[1, 2, 3]@find((n) => return n === 2)`
>>
> The definition of x@y(...args) is y.call(x, ...args) right? That's an
> interesting idea. This very syntax seems to collide with relationships [2],
> but maybe another syntax could work.
>
> But I am skeptical of any idea that requires adding syntax to the
> language, because it pushes further in time the solution.
> And since a library author can't force every library user to use a given
> tool (transpiler), I'm afraid library authors will prefer defining things
> on Array.prototype directly so everyone can use them right away.
>
> David
>
> [1] http://underscorejs.org/#find
> [2] http://wiki.ecmascript.org/**doku.php?id=strawman:**relationships<http://wiki.ecmascript.org/doku.php?id=strawman:relationships>
>
> Ps : totally unimportant, but "(n) => return n === 2" is a syntax error. I
> think the form without brackets need the RHS to be and expression and
> "return something" is a statement or something like that.
>