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

Le 18/08/2013 22:38, Alex Russell a écrit :
>
>
> On 18 Aug 2013 10:03, "David Bruant" <bruant.d@gmail.com 
> <mailto:bruant.d@gmail.com>> wrote:
> >>> * 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.
>
So TC39 will continue to extend the meta-protocol using double-underbar?
Is that an official thing? Are there new meta-protocol extensions in 
discussion I am not aware of?

> > 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?
>
Too bad you didn't bother answer that part...

> > 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.
>
1) Whatever, my "hoped policy" can change! Last sentence of my initial 
message was "This is of course an initial proposal and only the 
beginning of a discussion.".
2) François Rémy définition for prollyfill was "I wish browsers had it" 
and I think it's good for the future of the platform if these are 
prefixed so they don't collide with actual standard when they arrive. 
SugarJS made a Array#find prollyfill. Really wish they hadn't.
Not sure what a "preemptive polyfill" means, but if it's something that 
may not be standard, it'd be better if that was prefixed so it doesn't 
later collide.

> More to the point, your proposal is moot.
In my answer to François: "I want to solve the problem, not promote my 
solution at all cost.". If you agree on the problem and have a better 
solution, please make a better proposal and stop wasting time on my 
proposal.

David