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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
