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)
primordials wins.

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>
>>> 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/<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<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
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131013/d1151e0d/attachment.html>


More information about the es-discuss mailing list