Russell Allen <russell.allen at firebirdmedia.com> wrote:
> >> The VM doesn't appear to allow this to happen.  In fact, even creating a
> >> subclass of Object which implements #and: #or: etc seems to fall foul of
> >> the VM ("Non-Boolean Receiver - proceed for truth").
> >>
> >> Is there any way to get round this?  Do I have to rename all of the
> >> logic/control methods (ie something myAnd: [someblock])?
> >
> >There is a way - though it'll cost you *lots* of cycles. You could modify
> >the Compiler not to inline #and: and #or: and generate message sends instead
> >(you would have to modify several methods in MessageNode category 'macro
> >transformations'). Then, you could go on and recompile the entire system (to
> >get rid of the original transformations; cross your fingers that you didn't
> >do a mistake...). It'll slow you down *heavily* but it'll allow you to make
> >a new subclass of Boolean and implement #and: and #or: the way you want it
> >(as well as #ifTrue:ifFalse: if you'd like, heh, heh).
> >
> >Now the question is if that's really worth doing ... but I leave the answer
> >up to you ;-)
> >
> >  Andreas
> 
> Ugh!
> 
> Loosing cycles is not really an option (I never have enough as it is :)
> 
> Is it only the two messages #and: and #or: which are inlined?  Or are some
> of the others also done at the interpreter level?
> 


It's conceivable to have a smart system like in the Self system which
can inline arbitrary messages, not just #and:, #or:, etc.  With such a
system, you could avoid anomolies like you detected.  (Although watch
out when you add your new version of things like ifTrue: -- the system
have to dump the optimized versions of half the methods in the system,
and it will take a while for everything to get recompiled!)

Anyway, this probably doesn't help your immediate problem very much!

Lex