On Wed, 7 Jun 2000, Mats Nygren wrote:

[snip]
> BTW, do you know that
> 
>   a < b ifTrue: [whatever] ifFalse: [whateverElse]
> 
> is not done with polymorphic message send. The ST80 syntax is no great
> help for showing that.
[snip]

It's completely misleading to say that. There is a standard optimization
technique, that most extant and historical implmentations have used, for
this pattern. That is to inline it. A consequence of that technique is
that if you *were* to add #ifTrue:ifFalse to another class, you would
complicate the optimization. If the optimizer can *assume* that there's
only a fixed number of implementors, then it's life is much easier.

(Note: you don't have to go to a Self-like implementation to make
#ifTrue:ifFalse "fully polymorphic", though that would certianly do it. A
tuned cache or other optimized lookup system could work. Er...I mean you
might be able to do statically for limited cases what Self did
dynamically. It think Smalltalk/X allows some of this.)

The point is, that for most *implementations*---and for most
*situtations*---there's no need to make #ifTrue:ifFalse optimized under a
"full polymorphism" assumption. The conditions under which having
#ifTrue:ifFalse multiply implemented that it's reasonable to say, "keep
general speed by using a slightly different selector", or "endure the
slowdown until you figure out what your doing", or "if you want this, dork
with the optimizer to handle it".

But both syntactically and semantically, #ifTrue:ifFalse is a polymorphic
message send, and is most productively thought of that way.

Cheers,
Bijan Parsia.