[self-interest] Issues about delegation

[Jecel Assumpcao Jr]

On Wednesday 05 November 2003 17:45, J. Baltasar García Perez-Schofield 
wrote:
>          Yeah, but I mean, if you don't have copy-on-write slots,
> then you should copy all data slots (attributes) of prototype object
> X in prototype object X' when you create it, deriving from  X.

Exactly, though it is easy to set up the system to do this automatically 
for you. Every time you see a pink slot in an outliner, it has been 
copied-down from a parent by the system.

A bit of Self history might help, here. From 1.0 to 3.0 we programmed in 
Self by typing text into some external editor and then reloading it by 
typing a command at the prompt. Since the same file might be loaded 
multiple times during a session, the usual style was something like

   traits _AddSlotsIfAbsent: (| person = () |)

   prototypes _AddSlotsIfAbsent: (| person = () |)

   traits person _AddSlots: (| parent* = traits clonable.
                               otherStuff....
   |)

   person _AddSlots: (| parent* = traits person.
                        name <- 'John Doe'
   |)

Note that the _AddSlotsIfAbsent: parts won't do anything the second time 
the file is read in - we want to patch the existing objects instead of 
replacing them. This is subtle and very important!

A totally different file might have

   traits _AddSlotsIfAbsent: (| employee = () |)

   prototypes _AddSlotsIfAbsent: (| employee = () |)

   traits employee _AddSlots: (| parent* = traits person.
                               moreStuff....
   |)

   employee _RemoveAllSlots

   employee _AddSlots: person

   employee _AddSlots: (| parent* = traits employee.
                        number <- 423
   |)
  
Now employee has whatever slots a person has, plus its own parent and a 
number. You had to manually reload the file defining employee whenever 
there was a change to person, but that was easy to arrange.

So you see, "shape inheritance" was not a problem in practice in the 
early history of Self. When the graphical environment was introduced in 
4.0 (actually it might have started in 3.0 with annotations, but who is 
counting?) the "copy-down" mechanism was introduced to automate this 
development style.

In practice, if you look at how many pink slots you can see in the 
system, the problem isn't such a central one.

>          That raises another issue: dynamic inheritance. You should
> copy all atributes of the parent prototype object each time the
> 'parent' slot changed ...

That might seem to make sense, but it really doesn't. If you copy the 
state of a parent, then your local copy is exactly the same as that 
parent's. Why not just use its slots instead? You might be planning to 
change your local copy, but won't it get thrown away the next time you 
change parents?

So it only makes sense to have local state that is used by methods in 
all parents, and use the parent's state for specific stuff. The isn't 
the case when you have "roles" or "viewpoints/perspectives" (see the Us 
language), but then you have a bit more infrastructure than just 
dynamic inheritance.

>          It seems that the issue of attributes complicates the
> inheritance-using-delegation approach.

It complicates everything. So let's just have methods instead.

-- Jecel