Scoped binding of a method to an object

Brendan Eich brendan at mozilla.com
Sun Oct 13 10:19:28 PDT 2013


Apologies for the (iPad + haste)-induced typos below :-(.

/be

> Brendan Eich <mailto:brendan at mozilla.com>
> October 13, 2013 10:17 AM
> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Benjamin (Inglor) Gruenbaum <mailto:inglor at gmail.com>
> October 13, 2013 12:54 AM
> Scoped binding of a method to an object
>
> Well, I know how some languages solve this issue but I wondered if 
> ECMAScript considered addressing this or already have and I missed it.
>
> Often, I want to extend objects, for example -
>
> Array.prototype.shuffle - takes an array and shuffles it.
>
> 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?)
>
> 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.
>
> Stuff like underscore _.shuffle makes for less object oriented code, I 
> find it harder to write and it feels like the code is not where it 
> belongs.
>
> What I'd like is a way to add such methods in a scoped way, so within 
> /my/ code I get to use .shuffle but any code that is not in that 
> scoped block does not get access to this method.
>
> Has there been a proposal or discussion about this in the past?
>
> Benjamin Gruenabum
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list