<html><body bgcolor="#FFFFFF"><div>Yes, there's the rub. "private" != "protected".</div><div><br></div><div>/be<br><br>Sent from my iPad</div><div><br>On Jun 7, 2011, at 5:24 PM, Kam Kasravi <<a href="mailto:kamkasravi@yahoo.com">kamkasravi@yahoo.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><div>Thanks Mark, Brendan</div><div><br></div><div>Within this context subtype access and it's interactions with private would also be of interest to me. For example </div><div>interactions with <span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">static private  const.</span></div><div><br><br></div><div><br>On Jun 7, 2011, at 4:51 PM, "Mark S. Miller" <<a href="mailto:erights@google.com"><a href="mailto:erights@google.com">erights@google.com</a></a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>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. <div><br></div><div><br><div class="gmail_quote">On Tue, Jun 7, 2011 at 4:07 PM, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.com"></a><a href="mailto:brendan@mozilla.com"><a href="mailto:brendan@mozilla.com">brendan@mozilla.com</a></a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Jun 7, 2011, at 3:31 PM, Mark S. Miller wrote:<br>
<br>
> 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.<br>

<br>
</div>How could you tell? I mean, what reflection APIs would not disclose static privates as properties?<br>
<br>
Since <a href="http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects" target="_blank"></a><a href="http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects"><a href="http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects">http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects</a></a> 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.<br>

<br>
From <a href="http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects#open_issues" target="_blank"></a><a href="http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects#open_issues"><a href="http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects#open_issues">http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects#open_issues</a></a> 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?<br>

<br>
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.<br>
<br>
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.<br>
<font color="#888888"><br>
/be<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>    Cheers,<br>    --MarkM<br>
</div>
</div></blockquote></div></blockquote></body></html>