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_objectsare > 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_issuesI > 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
