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

Le 18/08/2013 18:53, Alex Russell a écrit :
> On Saturday, August 17, 2013, David Bruant wrote:
>
>     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
>
>     (...)
>
>     Initial Proposal (future-facing, but assuming backward compat,
>     obviously):
>     (...)
>     * 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
who is "we"? Google Chrome?

> 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.
ES6 adds @@iterator and @@create (symbols) and not __iterator__ and 
__create__. It looks like the way forward to extend the meta-protocol is 
symbols, no?
Beyond what's necessary for web compat (__proto__, 
__defineGetter__&friends), I feel it's easy for browsers to commit to 
this constraint?

>     * 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.
I touched on that in my "not all devs will get the memo" section above. 
Given the distributed nature of the web, it's impossible to get the 
committment. It doesn't mean we can't have a principle agreement.

> Polyfills and prollyfills put the lie to this immediately.
I answered that point in my answer to François Remy. Polyfills aren't 
really an "extension". They are a "userland JS" implementation of a 
spec, so no big deal.
Note that it might be an occasion for libraries to settle on the "is a 
polyfill worth adding if it cannot be 100% compliant?". It could be 
decided that actual polyfills go unprefixed and partial polyfills go 
prefixed.

David