Scoped binding of a method to an object

Erik Arvidsson erik.arvidsson at gmail.com
Sun Oct 13 10:32:23 PDT 2013


We did proposes this back in 2011

http://wiki.ecmascript.org/doku.php?id=strawman:scoped_object_extensions

I wasn't at this actual F2F meeting so I don't know many details.
Brendan might remember what the blocking issue was?

On Sun, Oct 13, 2013 at 1:19 PM, Brendan Eich <brendan at mozilla.com> wrote:
> 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
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



-- 
erik


More information about the es-discuss mailing list