dynamic inheritance (was: resend)

[Jecel Assumpcao Jr]

J. Baltasar Garcia Perez-Schofield" wrote on Mon, 07 Nov 2005 19:53:33
+0100
> 	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
> first one.

Exactly.
 
> 	I'm very interested. My own virtual machine assumes that parent
> attributes can be changed anytime (not currently, sadly).
> 
> 	http://trevinca.ei.uvigo.es/~jgarcia/TO/zero/
> 
> 	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 :-).

Normally each object is associated with a "map" that represents its type
to the virtual machine (pointers to maps are used in PICs and other
places). My change was to allow a single object to be associated with
more than one map (up to five) and was based on observations about how
dynamic inheritance is used in practice: normally a parent data slots
holds one among a few objects. So you have

_AddSlots: (| obj = (| parent* <- emptyTraits.
                    elements <- list copyRemoveAll |)
|)

...

obj parent: fullTraits.

...

obj parent: obsoleteTraits.


In this case there would be created a total of three different maps for
obj and 'parent:' would not be a simple assignment slot but would have
code to switch the map whenever it is executed. Since separate native
code is generated for a given message for each different map the lookup
happens at compile time just as if 'parent' were a constant slot.

A far more complicated case is when an object does not have itself
dynamic inheritance but one (or more) of its ancestors does. If this is
common enough then my scheme can be extended to handle it but it is
probably better to fall back on the "loop up every time" solution for
this. There is nothing special about my five maps per object limit but
like the limits in the PICs sizes after a point the advantages over the
general solution are no longer worth it.

> 	So you create your objects by joining mixins, perhaps ?

Exactly. I call them "facets" since they are used a bit differently than
traditional mixins and reusing the name might cause some confusion.
These facets (sets of slots) are ordered so it is easy to see (literally
given the visual representation) which slot will match each message. If
Self were converted directly to such a scheme most objects would be huge
due to the globals but I don't have globals in the language, though the
programming environment has a catalog that does the same job (but at
edit time, not run time).

-- Jecel