Eric,
Thanks, for your answer, but it sounds like a hacking technique
 for me (yes, 100%Smalltalk, but a hack :).
I feel that adopting the mechanism as a "basical behaviour" in Smalltalk
 (as #doesNotUnderstand:) has the benefit that do not alert the reader
 (hiding the real sourcecode can be difficult to debug).
Another problem that I found is that the lookUp is not done
 by the VM (loosing speed) and the methods implementing the
 lookup can't be patched that way.
I have been working in a transfer mechanism to build
 small sized images (image seeds that grow eating methods
 & classes dynamically from a parent image through a comm channel).
I am thinking in the replacement of all (possible) methods
 by ONLY ONE object (to save image space).
I have implemented a replacement method that uses
 the current context to find receiver,message & arguments;
 the problem can be solved this way; but I think that it is not
 a "clean" implementation. (nothing more clear that not to
 implement it, like when handling #doesNotUnderstand:).

If we adopt a clear & explicit way to handle the problem
 of notACompiledMethod for a selector, the idea
 can be propagated to other Smalltalk providers...
Also we will solve the crash of VM for malformed method dictionaries,
 because they can be debugged.
Now the VM crash and all the objects dead immediately.

Ale.

----------
De: 	Eric Arseneau[SMTP:eat at huv.com]
Responder a: 	squeak at cs.uiuc.edu
Enviado el: 	Jueves 23 de Marzo de 2000 00:31
Para: 	squeak at cs.uiuc.edu
Asunto: 	RE: anObject acting as aCompiledMethod

You can do the same thing that you are asking for without having to revert
to changing the VM.

Here is a possible way to do it.  It has the cost of an extra lookup to find
the "real" method, but the plus side is that it is done in Smalltalk where
it can be controlled much more easily. Here goes
	1) Create a subclass of compiled method, call it ProxyCompiledMethod
	2) This new class has the result of compiling something like:
		proxyMethod
			(self methodLookupMechanism findMethodForSelector: #proxyMethod object:
self)
				performOn: self
	3) Note that the above can be built to handle any number of args.  Also
performOn: is probably not correct, but something like it would work.
Somebody help here
	4) Override the sourceString method to return the appropriate source you
would like to see, instead of the above source.  This way the user sees the
correct code and no tools need to be changed.
	5) Override the compile mechanism, the class is asked for it's compiler.
Make it do whatever is appropriate, build a method object managed by
something else and keep it.
	6) Your done

I know the explanation is not as detailed as could be, but I hope you can
get the idea.  The point is that there is enough power there to change the
behavior the way you would like.  The hard part is changing the true method
lookup of a class, which has been talked about before.  It would be cool to
be able to change the method lookup mechanism of an object from with
Smalltalk.  Whether this is really practical or not is another issue.  But I
believe that the above gives you something appropriate.

Hope this helps ...

NOTE:  I used this trick to get my Java VM, written in VA Smalltalk, to do
this to handle interfaces.  I also use a method name mangling technique
which is not too original, but works.  I'm hoping to port the VM to Squeak
as soon as I can get some time and release it.

-----Original Message-----
From: Alejandro F. Reimondo [mailto:aleReimondo at sugarweb.com]
Sent: Wednesday, March 22, 2000 11:14 AM
To: 'Squeak List'
Subject: anObject acting as aCompiledMethod


As long as I know, we actually do not have a mechanism
 like #doesNotUnderstand: but for compiled methods...
When the message lookup success, the found compiled
 method is not checked by the VM as a real CompiledMethod
 instance. The VM assumes that the method is aCompiledMethod
 and activates a context...
If the found object is not aCompiledMethod, the VM crashes. :^(
Placing a little check when a method is found can be used
 to trigger a mechanism that send a "normal" message
 to the found method to evaluate.

e.g.
 1.-  VM lookUp for a method capable of solve the
   message to (aReceiver,selector,arguments)
 2.- if the found method aCompiledMethod
   isA: CompiledMethod => normal activation
 3.- if not a CompiledMethod then the VM can
     send message #evaluate: (or #value:) to the "compiledMethod"
     with aFullMessage (aReceiver,selector, arguments)
     as the argument

The implementation of a mechanism like this can be used
 to implement method wrappers or "proxyMethods".
This mechanism can be used to replace all the methods
 of a class with ONE object (the same object for all selectors)
 that load the methods from a server or from a parent image
 when needed.

Also we can implement pseudoMethods that can:
 x returns always anObject
 x return results of evaluating them (like one-argument blocks)
 x activates a context in an alternate virtual machine (with diferent
ByteCode set)
 x forward the message to a remote VM
......

hope that it can be interesting to implement behavior wrappers
 and metaprogramming tools.

Cheers,
Ale.