W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

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

From: David Bruant <bruant.d@gmail.com>
Date: Sun, 18 Aug 2013 22:59:14 +0200
Message-ID: <521135A2.30605@gmail.com>
To: Alex Russell <slightlyoff@google.com>
CC: public-script-coord@w3.org
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 

Received on Sunday, 18 August 2013 20:59:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:18 UTC