Hi all.<br><br><div class="gmail_quote">On Wed, Nov 26, 2008 at 12:49 PM, Ramon Leon <span dir="ltr"><<a href="mailto:ramon.leon@allresnet.com">ramon.leon@allresnet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">><br>
> Hi all.<br>
><br>
> What would people's reaction be if a class was prevented from<br>
> being able to directly access its superclass's instance<br>
> variables?<br>
<br>
</div>I would object.</blockquote><div><br><br>I'm interested in why you'd object. Do you have a deeper reason than "it makes coding harder"?<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">
> Is there any particular reason subclasses get access to<br>
> superclass instance variables? I think it breaks encapsulation.<br>
<br>
</div><br>Then we have different definitions of encapsulation. To me encapsulation<br>
means one object can not directly access the state of another object but<br>
must use messages for communication.<br>
<br>
If class #B inherits from class #A an instance of class #B is only *one<br>
object*; i.e. super is not another object but the same object as self and<br>
thus the object should have direct access to *all* of its own instance<br>
variables regardless of where they lie in the inheritance tree. I don't<br>
think encapsulation was intended to protect an object from itself. That's<br>
my 2 cents!<font color="#888888"><br>
</font></blockquote></div><br><br>I'm referring to encapsulation of an implementation of something. If a superclass is an "implementation of something", a subclass is a user and extender of that "implementation of something". Allowing a subclass direct access to the innards of its superclass prevents that superclass from being able to protect its carefully guarded state from meddling by subclasses.<br>
<br>This is relevant in the area of secure programming for my SecureSqueak project, although I can't think of a good example yet where it would really be a problem. <br><br>Say you have a class with a carefully guarded secret in it. It would then be possible for untrusted, remotely loaded code to be a subclass of that class and then give out that secret. This makes several assumptions though: firstly that you can somehow create an instance of your subclass with that secret state (which is unlikely) and secondly that the remotely loaded code actually has access to the class and is able to become a subclass of it. <br>
<br>Gulik.<br><br>-- <br><a href="http://people.squeakfoundation.org/person/mikevdg">http://people.squeakfoundation.org/person/mikevdg</a><br><a href="http://gulik.pbwiki.com/">http://gulik.pbwiki.com/</a><br>