> Hi, Mike:
> 
> Thanks for the comments!  This was just one of those "bolt out of the 
> blue" things, and I didn't know whether there was merit in it, or 
> underlying fatal problems that others have caught before.

Hi.
I just got bad news this week... No more Smalltalk.
Only Java.  I am pissed, so I'm trolling c.l.s and squeak-list to
avoid the innevitable.

> >A) He uses a single delegate.  One could imagine having multiple delegates,
> >   with some sort of conflict resolution mechanism.
> 
> Yes, I was thinking that you might want to have an OrderedCollection of 
> delegates for generality, but didn't want to whip all that up for a 
> simple posting.

I used to "Half-jokingly" offer up the following model of MI:

	When an object recieves a message it does not understand,
	it randomly selects an variable that contains an object that
	CAN respond to the message and it forwards it to said object.
	
	If that's not weird enough, variables are search for, first
	in the lexical scope of the most recent context (thisContext), 
	then in the lexical context of thisContext sender, all the way
	to the earliest stack frame.
	
	If that's not wierd enough, do the search by actually sending
	the message, and catching (or failing and possibly back-tracking) the
	DNU signal.
	
Watch those DNU's disappear!  One big advantage of Smalltalks's model
is that static, single inheritence is good enough for 99+% of the code.
If you want something more complicated, you are better off implementing
it yourself (ala the scheme you outline, or something else) lest you
wind up with a complex model that still doesn't do what you want (like C++,
or the model I proposed above).  There are just too many directions to
extend a static, single inheritence model for one of them to be the end-all
and be-all.

Of course, Smalltalk sorely needs a richer MetaObject Protocol.
(E.g.  It would be nice to have a SlotDescription class whose instances
would 'name' instVars, rather than using a String or Symbol)

> 
> 
> >B) The delegate is static.  If the interface of delegate changes
> >   (by any of a number of means, not the least of which is putting
> >   a different object in the 'delegate' slot)
> >   then the 'cache' of CompiledMethods may no longer be valid.
> 
> Good point.  Any ideas on how to detect and handle this?  I would think 
> that the delegate class would remain rather static (as the purpose is to 
> emulate MI "mixin"), but other things could cause the "cache" to become 
> stale.

It depends on whether you consider this a programmer's aid, or an
implementation technique.

-- Mike Klein