Scoped binding of a method to an object

Brendan Eich brendan at
Sun Oct 13 11:05:05 PDT 2013

> Till Schneidereit <mailto:till at>
> October 13, 2013 10:44 AM
> On Sun, Oct 13, 2013 at 7:17 PM, Brendan Eich<brendan at>  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:
>> 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.

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

> 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 

> If we ever manage to introduce better syntax for by-symbol property
> lookups, that problem would be thoroughly solved.

The challenge is to do so without adding another (even static-only, not 
reflected in the heap) binding rib.

> [1]:

More information about the es-discuss mailing list