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

On Aug 18, 2013 4:59 PM, "David Bruant" <bruant.d@gmail.com> wrote:
>
> Le 18/08/2013 22:38, Alex Russell a écrit :
>>
>>
>> On 18 Aug 2013 10:03, "David Bruant" <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

At least part of the debate here is whether or not something which is
definitely "I propose ” (prollyfill) and not ”i am providing a conforming
implementation to a done deal standard because it doesn't exist in 1 or
more browsers” (polyfill) should be mucking about in global space.  Truth
is, it is awfully hard to fully avoid because of interrelationships with
existing stuff.  Several don't even try- I think that is more dangerous
than necessary - it is plausible to adopt patterns to avoid the worst
footguns...this has been discussed on our list at length.  Part of the
problem I think is also disagreement on who/how these features should be
used.... Are they merely for experimental things, or for use in
production.   I think history shows that the former is impractical - see
anything vendor prefixed as an example. The later is more valuable for
understanding how useful an api is and, given that we know it will happen,
I certainly don't want people blaming my code for thousands of websites
when code that has worked for a long time suddenly stops and breaks their
site when browsers push out an update which has a different and confirming
implementation with the same name.