[self-interest] resend (was: Multiple inheritance)
J. Baltasar Garcia Perez-Schofield
jbgarcia at uvigo.es
Mon Nov 7 18:53:33 UTC 2005
> > That's the point.
> > But I suppose that this means that at runtime time, each time a
> > resend/"unqualified" message is sent, and more than one parent is found
> > for the receiver (and provided the receiver can't satisfy the message),
> > then all inheritance paths are explored in order to avoid the
> > possibility of finding more than one receiver (and show the debugger if
> > found).
> Correct except for the "provided the receiver can't satisfy the message"
> send the whole point of the resend is to skip any slots that the
> receiver might have with that name.
Mmmm ... note I wrote resend/unqualified messages: as far as I
understood, "resend.copy" and "copy" would behave the same but for the
lookup in "self" which would happend in the second case but not in the
> Michael Latta mentioned PICs and maps and other virtual machine tricks,
> but I suppose that is what you mean by "the first time". Note that in my
> example all three parents were constant slots. And probably their
> parents too and so on. In such cases you can be sure that nothing will
> change between the first and second times.
I see. They are constant slots because they don't have an assignment
> If one of the parents had an associated assignment slot then you would
> be correct: a lookup would have to be repeated on each message send. But
> in practice such dynamic inheritance is rarely used. I actually came up
> with a way to greatly speed up this situation but it didn't seem worth
> the effort. And I eliminated this feature entirely from my own Neo
> Smalltalk design.
I'm very interested. My own virtual machine assumes that parent
attributes can be changed anytime (not currently, sadly).
So maybe you could explain what exactly you thought as a solution.
Although I am not working in that part of the VM, my first design to
overcome this is to employ an observer pattern and make references
observers of the attributes they must have to pass through in order to
get to an object.
Of course, another always-secure possibility is to recalculate a given
reference each time it is employed :-).
> As Self currently is this would be very likely since you add the slots
> graphically and they are shown in alphabetical order.
Yes, that's a problem. My VM also currently sorts members of each
object alphabetically, I mean internally, though it doesn't offer
> But for some
> scripting language this might be an interesting option. In early
> versions of Self/R I did have a depth first search exactly as you
> suggest but around the time I changed the name to Neo Smalltalk I
> decided to get rid of parents entirely and make the programmers manually
> order the "facets" which make up an object.
So you create your objects by joining mixins, perhaps ?
PBC -- J. Baltasar García Perez-Schofield
jbgarcia en uvigo de es http://webs.uvigo.es/jbgarcia/
Dep. Informática, Universidad de Vigo, España (Spain)
More information about the Self-interest