Scoped binding of a method to an object

Till Schneidereit till at tillschneidereit.net
Sun Oct 13 11:28:48 PDT 2013


On Sun, Oct 13, 2013 at 8:05 PM, Brendan Eich <brendan at mozilla.com> wrote:
>> Till Schneidereit <mailto:till at tillschneidereit.net>
>> October 13, 2013 10:44 AM
>>
>> 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.
>
>
> The problems with those are not definitive enough for library authors to
> give up usability, from all evidence.
>
> SugarJS from [1] is a case in point. It won not just because it beat TC39 to
> the punch, but because it could work its will on the mutable built-in
> prototypes.

And now it causes problem for TC39, browser vendors, sites that use it
and end users. (The last group should be affected the least because
the first three groups work together to prevent it, of course.)

>
> The unscopable proposal arose due to 'with'. Many people avoid 'with' (all
> JSLint users). That's even less definitive an objection.

It's used, though, and will keep being used, I'm afraid.

>
>> 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.
>
>
> Good reason to get TC39 out of the library evolution business, in my view!
> Github does much better. The standards body can codify de-facto winners.

I wholeheartedly agree on not doing library evolution in TC39.
However, GitHub-based evolution doesn't always (or, never does,
really) result in wins that are clear-cut enough that codifying them
won't break the web. If two heavily-used libraries add the same method
with slightly different arguments, that method can't ever be codified.


More information about the es-discuss mailing list