An "extend" operator is a natural companion to <|

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Jul 19 14:44:39 PDT 2011


On Jul 19, 2011, at 11:16 AM, Brendan Eich wrote:

> On Jul 19, 2011, at 11:07 AM, Bob Nystrom wrote:
>> 
> 
> 
> 
>> // "private" before a section lets you declare private members on that object.
>> private new:
>>   health;
> 
> Not sure we need 'new' there given lack of private prototype properties in the proposal. It's a bit verbose. Probably even if we add private prototype properties we can let private: (in this idea you've pitched) default to private instance.
> 


Any useful for class design is going to want to be able to have non-public methods.  And there are good use cases for private data that is shared among instances (for example example large lookup tables).

Also, ust a reminder that if "privateness" is based upon Private Names then there are point of use issues with undecorated property name identifiers.  EG:

    foo.health //foo might or might not be an instance of this class

which is why we might need to distinguish

    foo[health]
from
   foo[@health]
or possibly
   foo at health

Also, if
    private new;
          health

introduces a new Private Name valued lexical binding for "health" or (even @health) then we need to deal with the scoping of that binding.

These were largely topics of another thread which I want to get back to with some new thoughts.  But these issue may have impact of details of the direct of the design discussion in this thread.  I don't think it works to try to add private property access issues into the design after everything else is settled.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110719/8491e1a5/attachment.html>


More information about the es-discuss mailing list