[self-interest] resend (was: Multiple inheritance)

[Michael Latta]

This is the conceptual way it happens.  Under the covers the VM generates
something quite a bit more efficient.

For each method invocation in the system it points to a table that has a
mapping of object type to method body.  This polymorphic cache is what makes
self based vms (HotSpot in java uses this) unique.  In the case of Self the
"type" is computed dynamically based on the slots of the object and the
inherited behaviors.  This web of dynamic typing is maintained under the
covers as objects are modified.  For example if an object is cloned they
both have the same "type" until one has a behavior slot change.  Once that
happens then a new type is created for the modified object.  There is logic
in the system to reduce like types to the same type so there is limited type
fragmentation.

Michael
 

-----Original Message-----
From: self-interest at yahoogroups.com [mailto:self-interest at yahoogroups.com]
On Behalf Of J. Baltasar Garcia Perez-Schofield
Sent: Monday, November 07, 2005 8:34 AM
To: self-interest at yahoogroups.com
Subject: Re: [self-interest] resend (was: Multiple inheritance)


	Dear Jecel:

	Thank you again for your explanation.


> ( | parent* = traits clonable.
>      sharedStuff* = mixins utilities. "just an example - not in Self
> distribution"
>      moreStuff* = mixins graphics. "another example"
>      subElements <- list copyRemoveAll.
>      copy = ( | new |
>                     new: resend.copy.
>                     new subElements: subElements copy.
>                     new ).
>       .....
> | )
> 
> The "resend.copy" will do exactly the same (full) search that just
> "copy" would have done except it will skip the local methods in the
> object, which in this case is the very method doing the resend.

	Yes, as "super" in Java.

>  That
> means that any copy slots in "parent", "sharedStuff" and "moreStuff"
> will be found and if there is more than one then a debugger will pop up.

	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).
	This can't be limited to the first time because Self is dynamic, the
inheritance paths can change after a message is carried out due dynamic
inheritance. So Self has to do it every time, and I guess this is quite
expensive.
	Or maybe I am missing something ?

	The depth search is maybe problematic in some sceneries, but is
obviously better in the best case (the receiver is found in the first
inheritance path) and in the average case, though equal in the worst
case.

> An alternative would be to replace "resend.copy" with "parent.copy" (for
> example) and in that case a "copy" slot in either "sharedStuff" or in
> "moreStuff"

	More or less as in C++ with "SomeParent::foo()", I guess. Yes, I
understand you can void any search by directly indicating the
"inheritance path" you are interested in.

> Some people prefer a depth first search but that has a nasty side effect
> that just changing the order of "sharedStuff" and "moreStuff" in the
> above code could change its meaning!

	Absolutely.
	However, is it likely to happen ?. I mean, if a programmer knows
that
order of parents in the parent list (whatever syntax you choose) has a
meaning, would that programmer change the order of parents without
noticing ?

	Regards,

		Baltasar

-- 
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)



 
Yahoo! Groups Links