Harmony:classes static and private

Brendan Eich brendan at mozilla.com
Tue Jun 7 18:02:35 PDT 2011


Yes, there's the rub. "private" != "protected".

/be

Sent from my iPad

On Jun 7, 2011, at 5:24 PM, Kam Kasravi <kamkasravi at yahoo.com> wrote:

> Thanks Mark, Brendan
> 
> Within this context subtype access and it's interactions with private would also be of interest to me. For example 
> interactions with static private  const.
> 
> 
> 
> On Jun 7, 2011, at 4:51 PM, "Mark S. Miller" <erights at google.com> wrote:
> 
>> I agree with all of this. It does seem bizarre to resort to private names for a use case addressed well by lexically captured variables. But yes, we could do either. 
>> 
>> 
>> On Tue, Jun 7, 2011 at 4:07 PM, Brendan Eich <brendan at mozilla.com> wrote:
>> On Jun 7, 2011, at 3:31 PM, Mark S. Miller wrote:
>> 
>> > We have talked about adding some way to state class-private per-class variable declarations without having to place them textually outside the class. However, a problem with "static private" is that it suggests that such things are properties. They're not. They're just lexically captured variables.
>> 
>> How could you tell? I mean, what reflection APIs would not disclose static privates as properties?
>> 
>> Since http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects are in Harmony, it's not a given that static privates must be lexically captured as in a power-constructor pattern. It should not be observable apart from reflection.
>> 
>> From http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects#open_issues I think we have some freedom to restrict reflection APIs from seeing any private names. That leaves proxies, but with class static private (or should that be private static? ;-)) members, a Proxy can't get in the middle. Can it?
>> 
>> Between the open issues on private name objects and the private(this) placeholder and related open issues on classes, I believe we have some room to maneuver.
>> 
>> My point here is not to argue that we must have static private class members. Only that we could consider them as distinct from lexically captured private upvars a la the power constructor pattern.
>> 
>> /be
>> 
>> 
>> 
>> 
>> -- 
>>     Cheers,
>>     --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110607/608ed8af/attachment-0001.html>


More information about the es-discuss mailing list