On Sep 23, 7:43pm, Brad Might wrote: } This is what I have tried, is it the way to go ? } } } prototypes _AddSlots: (| } animal = (| } parent* = traits animal. } "object specific stuff here". } |). } mammal = (| } parent* = traits mammal. } inherit**. "at initialization (copy), this slot will be } filled in with a copy of prototypes animal"
You are not the only one to ponder exactly how to do this. Particularily nasty is that changing the animal prototype doesn't affect the inherited slots of mammal at all. Of course, it doesn't affect any existing animals either. I was hacking on `copy-on-write' slots at one point, but this as was with 1.1, and one couldn't use _AddSlots: from within a method... I think that something like that is the solution.
[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
self-interest@lists.selflanguage.org
-
mcr＠latour.sandelman.ocunix.on.ca -
Urs.Hoelzle＠Eng.Sun.COM