Scoped binding of a method to an object

Till Schneidereit till at
Sun Oct 13 10:44:38 PDT 2013

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.

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.

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

>> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list