On 25-Nov-2008, at 9:20 PM, Michael van der Gulik wrote:
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".
Well, umm, no, I don't think so -- a subclass is, by definition, an _extension_ of the class it inherits from.
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.
If such protection seems necessary then I'd say there's something extremely broken in the overall design of that part of the class hierarchy in question.
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.
Perhaps you could start by explaining some of the theory about how any kind of "secure" (do you really just mean "safe"?) programming techniques can be aided by what you seem to be describing here.
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.
Ah, perhaps you don't mean secure programming, but rather actual data security.
I really don't understand your security model here. It doesn't seem to be related to or compatible with the object oriented programming model of Smalltalk at all, at least as I understand things. A subclass is an extension of its superclass. An object which is an instance of the subclass inherits all the qualities of the superclass(es) too.
An object that is only derived from the "superclass" is a separate object. And it isn't an instance sharing any quality of any subclass that may inherit from its class, let alone sharing any data with any instance of any subclass.
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.
Indeed, that part is just plain nonsensical.
You seem to be confusing the definition of objects with the actual objects themselves.
If you're really trying to create a model where objects created as instances of classes which have been remotely loaded, then you need to create some sort of partitioned VM storage model such that the VM will only pass messages between objects within a given partition, and perhaps one way from a parent partition. I don't think this can really work very well in a Smalltalk system though, but perhaps I'm missing something. If I load untrusted code I basically have to do it in a different VM image which has been carefully constructed so as to contain only public data and which has built-in controls which will only allow it to access those parts of the outside system environment which I would feel safe allowing untrusted code to access. Perhaps this VM image could be dynamically created and managed by another full "parent" VM. If I'm not mistaken this is kind of sort of how the Java VM security model is supposed to work.