<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jun 8, 2011, at 8:14 AM, Mark S. Miller wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div style="word-wrap:break-word"><div>The "private record" especially views as an "object" is a kind of placeholder too. It doesn't help to think of it as a record. It probably does not help to think of it as an object, either, especially if you cannot get at it via anything like the still-straw private(this) or private(other) syntax.</div>
<div><br></div><div>On another topic, it does seem like "protected" is inevitable, doesn't it?</div></div></blockquote><div><br></div><div>Actually, it isn't another topic. It's why Kam's GilaMonster cannot see Monster's "health". </div></div></blockquote><div><br></div>My topic changed from "private record/object", 'sall ;-).</div><div><br></div><div><br></div><div><blockquote type="cite"><div class="gmail_quote"><div>"private" means "private to the class", not "private to the class and subclasses". "protected" would mean the second, and no, I don't think it's inevitable. </div></div></blockquote><div><br></div>It's not, we can choose to hold the line -- question below, though.</div><div><br></div><div><br><blockquote type="cite"><div class="gmail_quote">
<div>E and Caja have been doing very well with "private", "public", and inheritance, and I've only ever been frustrated by the lack of "protected" once in a blue moon. And it was always easy to work around its absence. Given ES-next's private names and weak maps, it becomes even easier to work around the absence of "protected".</div></div></blockquote><div><br></div>You can make all kinds of friend relations with lexical scope and weak maps, it's true. But these can have the same cost problem that led to the private instance variable goal:</div><div><br></div><div>* An efficient implementation. The private state should be allocated with 
the instance as part of a single allocation, and with no undue burden on
 the garbage collector.</div><div><br></div><div>(from <a href="http://wiki.ecmascript.org/doku.php?id=harmony:classes#private_instance_members">http://wiki.ecmascript.org/doku.php?id=harmony:classes#private_instance_members</a>).</div><div><br></div><div>Private name objects can be shared via lexical scope and used more efficiently to address a property on a base class from both base and subclass, where the property storage is conceptually packed, and implementations can do their best, as with any ad-hoc property added non-declaratively. But such properties will not be part of the declarative class instance state.</div><div><br></div><div>Having declarative syntax in the constructor body for public and private variables serves several goals, not just efficiency. Also, private name objects must be accessed using [] not dot.</div><div><br></div><div>We can say "for protected, use these patterns". But patterns are not always the best solution. As Peter Norvig said they often show bugs in one's programming language.</div><div><br></div><div><br><blockquote type="cite"><div class="gmail_quote"><div>Btw, in both C++ and Java, the semantics of "protected" is a mess, in different ways.</div></div></blockquote><div><br></div>Sure. Let's not make those mistakes. Non-fixable in your view?</div><div><br></div><div>/be</div><div><br></div></body></html>