[self-interest] Re: Multiple inheritance

Jecel Assumpcao Jr jecel at merlintec.com
Sat Nov 5 19:58:37 UTC 2005

"J. Baltasar Garcia Perez-Schofield" wrote on Fri, 04 Nov 2005 20:30:06
> 	If you refer to two methods in different "paths of inheritance", then I
> suppose Self just begins with the first parent attribute until it finds
> the method it is looking for. So the first one found wins over the
> others.

This would be a "depth first" search for slots, which as Ian wrote in
another message isn't how things are done in Self.

Self 1.0 and 2.0 had these features:

 - parent priorities indicated by the number of "*" in the slot name.
All parent slots of a given priority were searched together and only if
no slot with that name was found were parents of the next lower priority

 - privacy declarations would hide certain slots from searches depending
on which object had sent the message

 - the tie breaker rule was used when more than one slot with the same
name were found even with the above two features. It selected one of the
slots as the "right" one

High priority mixins were used do divide up very large objects into
smaller, named pieces.

The main problem with this combination of features is that sometimes a
slot would get selected as the "right" one which wasn't what you
expected and this was particularly hard to debug.

So in Self 3.0 we had these changes:

 - all parents have the same priority

 - privacy declarations are now only informative and have no effect on
slot lookup

 - no more tie breaker rule, so as Ian said you get an "ambiguous send"
error unless exactly one slot is found in a full search

 - object and slot annotations were introduced and this replaced
inheritance as a way to divide large objects. It also added a lot of
meta information that made the transporter possible

Self has always had two kinds of resends (like "super" in Smalltalk):
directed ones where you specify one parent to be search and undirected
ones with the word "resend" instead of a parent name which indicates
that all parents should be searched. Using the first kind you can work
around duplicated slot names but in the general case you will have to
refactor and/or rename things in your code to get it to work. In
practice this has proved to be much more usable than the original
automatic solution.

-- Jecel

More information about the Self-interest mailing list