Harmony:classes static and private

Mark S. Miller erights at google.com
Tue Jun 7 16:51:56 PDT 2011


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_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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110607/5f3bcc66/attachment.html>


More information about the es-discuss mailing list