Scoped binding of a method to an object
Mark S. Miller
erights at google.com
Sun Oct 13 11:25:14 PDT 2013
On Sun, Oct 13, 2013 at 11:03 AM, Benjamin (Inglor) Gruenbaum <
inglor at gmail.com> wrote:
> David Bruant <bruant.d at gmail.com> wrote:
> > 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.
> What if I use two libraries that polyfill `_shuffle` or `_last`
> differently (let's say with different behavior for an empty array for
> `_last` or weaker guarantee on the randomness in `_shuffle`)?
Whichever first freezes after polyfilling (or otherwise monkey patching)
If you want to do a "scoped" polyfill insensitive to such freezing or
conflicting monkey patching, use WeakMaps or (post ES6) relationships.
> On Sun, Oct 13, 2013 at 9:00 PM, David Bruant <bruant.d at gmail.com> wrote:
>> 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>
>>>> Benjamin (Inglor) Gruenbaum wrote:
>>>>> However, this is considered bad practice for many reasons I don't have
>>>>> repeat here (what if other libraries also override it? What if some
>>>>> code? What if it makes it to the standard some day?)
>>>> Actually, people say extending Object.prototype is bad practive
>>>> the original post, IIRC from Arv, said; yes, I recalled correctly:
>>>> 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 ( 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:
>> (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...
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss