Lexically Scoped Object Extensions (was About private names)

Brendan Eich brendan at mozilla.com
Tue Mar 22 00:09:04 PDT 2011


On Mar 21, 2011, at 11:50 PM, François REMY wrote:

> From: Brendan Eich
> Sent: 21 March 2011
>> On Mar 21, 2011, at 1:13 PM, Erik Arvidsson wrote:
>> >
>> > The above use case cannot be solved using private names because
>> > private names conflict with public names.
>> 
>> I don't see this, though. Don't oversell!
> 
> 
> I think it's true: you can't do this with private name.
> 
> private filter;
> Object.filter = function defaultFilter() { ... };
> [0, 1, 2].filter(...) // will triggers Object.filter and not Array.filter, because filter is not "filter" anymore but a private name instead.


Sure, but the problem (as people keep pointing out) has two solutions: close the scope in which filfter binds to a private name, or use a renaming private declaration.

It's not perfect but there's no absolute inability to call public filter and private filter.


> If you use a "normal name" with a reduced visibility instead, the classical prototype chain will continue to works as expected.

Is that what Erik et al. are proposing? From discussions today it seems either private names with strong encapsulation, or soft fields (weak maps), could be used to implement extend O with {...}. The crucial test would be when O is frozen. If the subjective extension still works in scope of the module declaring the extension, then soft fields or an equivalent must be what underlies the syntax.

/be


More information about the es-discuss mailing list