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

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

All new additions to javascript language or runtime can be imported through
@{{name}} modules. We can set up a rule that web developers should not
create modules that start with "@".

If necessary we 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)`

On Sat, Aug 17, 2013 at 7:08 AM, David Bruant <bruant.d@gmail.com> wrote:

> Hi,
>
> [I'm not entirely sure "non-agression pact" is the best expression. What I
> mean is "let's decide on a border and respect one another's border"]
>
> 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.
>
> 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.
>
> Before my initial proposal, I'd like to address some points:
> * A first limitation is that not all devs will get the memo. However, a
> good thing about an agreement between browsers and webdevs is that tooling
> can inform that the agreement has been violated and recommend what to do to
> respect the agreement.
> Also, people aware and caring of the agreement can have a reference point
> on what to do and what not to do to share with an open source library
> they'd have noticed not respecting the agreement. (For whatever reason, I
> can already imagine Rick Waldron or Dominic Denicola filing such issues on
> Github :-) )
> * This proposal also doesn't really help with existing deployed code
> (browser devtools integration may raise alerts and trigger fixes though)
> * 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 <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.
>
> I think technical and language-based solutions have been explored enough
> and shown to fail, so I believe an human-agreement-based solution (backed
> by static+dynamic tooling) is worth a try.
>
>
> The proposal I'm making here is in part documenting existing practice and
> in part trying to introduce new rules.
>
> Initial Proposal (future-facing, but assuming backward compat, obviously):
> * The global object is free for everyone (spec or webdevs) to write on it.
> Creating a global property should never fail for JS code.
> Among other things, this is supposed to prevent new APIs to define
> immutable global properties [2].
> This rules allows for instance jQuery to define "$" and "jQuery" global
> symbols without fearing that a spec may one day define immutable properties
> with these names.
> WebIDL tests may be able to enforce such a property. That may become a
> hard requirement for a spec to move to Last Call state for instance.
>
> * 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 (beyond the ones that may already exists for backward-compat
> reasons of course)
> WebIDL tests may be able to enforce such a property. That may become a
> hard requirement for a spec to move to Last Call state for instance.
>
> * Web developers commit to never extend a built-in unless the property
> name starts with '_'.
> This can be enforced by developers themselves via static tooling and human
> review or via browser devtools that can emit a warning in a webconsole
> explaining that for the good of the long-term of their application, web
> devs should change their code.
>
>
> This is of course an initial proposal and only the beginning of a
> discussion.
>
> David
>
> [1] https://mail.mozilla.org/**pipermail/es-discuss/2013-**
> July/032228.html<https://mail.mozilla.org/pipermail/es-discuss/2013-July/032228.html>
> [2] http://lists.w3.org/Archives/**Public/public-webapps/**
> 2013JulSep/0224.html<http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0224.html>
>
>