"is a" relationships
Urs.Hoelzle at Eng.Sun.COM
Thu Sep 24 18:27:28 UTC 1992
Michael> You are not the only one to ponder exactly how to do this.
Michael> Particularily nasty is that changing the animal prototype
Michael> doesn't affect the inherited slots of mammal at all. Of
Michael> course, it doesn't affect any existing animals either. I was
This indeed a classical Self problem (it is discussed in detail in the
"Organizing Programs without Classes" paper, by the way). The problem
is that class-based systems automatically "copy down" the instance
variables from the superclass to the subclass. In other words, they
*force* subclass instances to be an extension of superclass instances.
In Self, there are 3 ways to do this:
1. By hand.
2. With "data parents" as given in the example.
3. Through the programming environment.
I like 3 best: essentially, what you want to express is "the format of
this prototype is just like this other one, except that...(list of
adds/deletes goes here)". Essentially, this is just a constraint
between two objects, and the programming environment maintains this
constraint for you, giving you the convenience of class-like
representation extension without being forced to *always* use it.
(BTW, I think putting constraints in the programming environment is a
good idea anyway, for example to specify things like "this constant
equals this other constant plus one". Even in a class-based system
like Smalltalk, you can't specify things like that, and when you
change one constant, the other isn't updated automatically.)
A fourth solution would be to add "copy-down" slots to Self, i.e. data
slots that get copied down to anybody who inherits from the object.
But this would complicate the language (especially with DI :-), and
it is less general than constraints. (Cecil, Craig Chamber's new
language, has copy-down slots.)
More information about the Self-interest