Harmony:classes static and private

Kam Kasravi kamkasravi at yahoo.com
Tue Jun 7 17:24:54 PDT 2011


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/5a9c96a4/attachment.html>


More information about the es-discuss mailing list