On Wednesday, June 30, 2004, at 03:33 AM, Pavel Krivánek wrote:

> I think that the clearest solution is to modify the compiler. Remove 
> all
> optimalizations including jumps in bytecodes for ifTrue:ifFalse:, 
> caseOf:
> etc. Then recompile whole image. But this step will produce much 
> slower code
> :-(

Of course, the translator will counter that to some (unknown to me) 
degree.

Generally speaking, why aren't those bytecode handlers resending the 
message if the receiver isn't of the appropriate class?  Let the Object 
level implementations throw the error.   Sure, it's the same as the 
#mustBeBoolean solution, but the semantic would continue to be the 
original msg selector.  That makes a big difference.


>
> The other possible solution is to make special bytecode executor. It 
> should
> remove optimalizations on the fly. Processes which need to use proxies 
> will
> run in special simulated mode. It would be slow, but more general 
> solution.
>

I have seen the term executor used in VW somewhere, but I have never 
know what it is, and more importantly how it is used/implemented.  Does 
each process hold it's own executor, which dispatches the bytecode 
stream appropriately to that executor impl?  Perhaps each receiver 
could have an executor to customize bytecode dispatch per class.  This 
sounds interesting, especially if it can more efficiently and 
transparently handle proxies.

Rob