Scoped binding of a method to an object

Brendan Eich brendan at mozilla.com
Sun Oct 13 10:17:54 PDT 2013


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.

> The problem is even more prevalent in stuff like 
> String.prototype.contains which we know will be in the next spec - 
> people had little way to add that function to the string prototype 
> /before/ it was adapted to the spec and not get eventually bitten.

No, object detection, polyfilling, and even "prollyfilling" are common 
and successful adaptationsp on the Web.

Symbols help but (without dot syntax) also hurt. We'll see how much use 
they get in the future, but for the record, string-equated names have 
been and will be used to extend standard built-ins too.

Your subject recalls a defunct proposal to add lexically-scoped but 
heap-based -- therefore object property-lookup performance hindering -- 
extension properties. This proposal died precise because of the 
performance problem.

/be


More information about the es-discuss mailing list