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

On Saturday, August 17, 2013, David Bruant 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.
>

No? We're going to continue to extend the meta-protocol, and to the extent
that double-underbar properties are a good way to do that, I think we'll
continue.


> * Web developers commit to never extend a built-in unless the property
> name starts with '_'.
>

And you can't extract that concession from the "other side" as well.
Polyfills and prollyfills put the lie to this immediately.


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