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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
