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

On 18 Aug 2013 10:03, "David Bruant" <bruant.d@gmail.com> wrote:
>
> 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?

TC39

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

But they are. And they can conflict. And Prollyfills -- preemptive
pollyfills for emerging specs -- simply are not allowed under your hoped
for policy.

More to the point, your proposal is moot. You can't promise to enforce it
credibly, so you can't promise anything to TC39 about the be behaviour of
libraries.

Non-agression between non-combatants is a non-event.

> 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