"is a" relationships

[Urs.Hoelzle@Eng.Sun.COM (Urs Hoelzle)]

[example omitted]

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.)

-Urs