Le 13/10/2013 19:44, Till Schneidereit a écrit :
> On Sun, Oct 13, 2013 at 7:17 PM, Brendan Eich <brendan at mozilla.com> wrote:
>> Benjamin (Inglor) Gruenbaum wrote:
>>> However, this is considered bad practice for many reasons I don't have to
>>> repeat here (what if other libraries also override it? What if some user
>>> code? What if it makes it to the standard some day?)
>>
>> Actually, people say extending Object.prototype is bad practive (verboten,
>> the original post, IIRC from Arv, said; yes, I recalled correctly:
>> http://erik.eae.net/archives/2005/06/06/22.13.54/).
>>
>> Extending Array.prototype is less so, and PrototypeJS did it. Other
>> libraries extend built-in prototypes. Some even take care not to jump a
>> prior claim.
> Given the hoops we have to jump through because of Array.prototype and
> String#prototype extensions right now ([1] and Unscopable), I would
> argue that extending any builtins' prototypes without at least some
> poor-man's namespacing shouldn't be done, either.
>
> I do agree that poly- and prollyfilling can be quite convenient, but
> ISTM that the problems they create for the language's builtins library
> ability to evolve only increase over time.
Unless an agreement is found between the platform and authors on, for 
instance, a part of the namespace that'd be exclusively reserved to authors:
http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0430.html
(the wording is a bit too strong and some minor adjustements followed in 
posts, but this posts explains the idea well enough)

Concretely, attempted prolyfills, could be _-prefixed (that really fits 
with what you call "poor-man's prefixing", I believe)
Authors would feel free to add something like Array.prototype._shuffle 
or Array.prototype._last, or EventTarget.prototype._on without worrying 
about collision with the platform.
We need agreement from the platform though.

... we might not actually need agreement from the platform. Claiming the 
namespace, shipping a library using it and spreading the word about it 
on standard mailing-lists could be enough... but somewhat douchebaggy 
which is why I shied away from doing it so far...

David

Le 13/10/2013 19:44, Till Schneidereit a écrit :

> Given the hoops we have to jump through because of Array.prototype and
> String#prototype extensions right now ([1] and Unscopable), I would
> argue that extending any builtins' prototypes without at least some
> poor-man's namespacing shouldn't be done, either.
>
> I do agree that poly- and prollyfilling can be quite convenient, but
> ISTM that the problems they create for the language's builtins library
> ability to evolve only increase over time.

Unless an agreement is found between the platform and authors on, for 
instance, a part of the namespace that'd be exclusively reserved to authors:
http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0430.html
(the wording is a bit too strong and some minor adjustements followed in 
posts, but this posts explains the idea well enough)

Concretely, attempted prolyfills, could be _-prefixed (that really fits 
with what you call "poor-man's prefixing", I believe)
Authors would feel free to add something like Array.prototype._shuffle 
or Array.prototype._last, or EventTarget.prototype._on without worrying 
about collision with the platform.
We need agreement from the platform though.

... we might not actually need agreement from the platform. Claiming the 
namespace, shipping a library using it and spreading the word about it 
on standard mailing-lists could be enough... but somewhat douchebaggy 
which is why I shied away from doing it so far...