Yes, there's the rub. "private" != "protected". /be
Sent from my iPad On Jun 7, 2011, at 5:24 PM, Kam Kasravi <[email protected]> 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" <[email protected]> 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 <[email protected]> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
