"Raab, Andreas" 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 ;-)

I'm curious just how bad the speed hit is. It has been my experience, especially
in Smalltalk, that though something be slightly less optimal at a small
locality, the overall system performance loss/gain is minimal. Does anyone have
any numbers on such a mod?

And on another note... why does one have to remove the inlining? Can't he just
modify the inlining to support the trinary logic. Granted, the inlined trinary
may be slower than the inlined binary, but the message send overhead of such a
change should be able to be removed. A long time ago, when we added ifNil: and
ifNotNil: to VW, there was some hesitance to use them, because they were not as
fast as the doubly inlined isNil and ifTrue:, so we inlined it ('twas simple)
and they ran the same.

--
Travis Griggs (a.k.a. Lord of the Fries)
Member, Fravenic Skreiggser Software Collective
Key Technology
P-P-P-Penguin  Power!