The idea of a flat ban on #ifTrue:ifFalse: is ridiculous.
Number>>abs
�� ��^self negative ifTrue: [self negated] ifFalse: [self]
Is there any better way to do this?�� Not really, you can
only move the #ifTrue:ifFalse: somewhere else.
The main argument against #ifTrue:ifFalse: is NOT TO USE
IT FOR TYPE TESTS.�� If you want to do different things
depending on the class of x, ask x to do it.�� (The irony
is that in Smalltalk, #ifTrue:ifFalse: *is* in principle
an object-oriented dispatch.)�� If you want to do
different things depending on the state of x, and this
requires revealing internal details that would not
otherwise be revealed, ask x to do it.
Two key ideas in software engineering are coupling
(lots of interdependencies makes things hard to re-use)
and cohesion (modules/types/classes should be "about"
one thing).�� You have to balance the "use OO dispatch"
idea against this: you have a method in class A that
depends on an object of class B, and you don't want
A to have to know too much about B, but on the other
hand, you don't want B to have to depend too much on
what A is up to.�� If it makes sense to have a B without
any A around, then changes to A should not really
require changes to B.
So eliminating #ifTrue:ifFalse: from your code can make
it WORSE.�� You have to THINK about each task and decide
where it REALLY belongs.�� Is this bit of code entirely
about B?�� Then it belongs in B.�� Is that bit of code
about already public information concerning B and also
tied to A's needs and wants?�� Then it belongs in A.�� And
if that means using some sort of "if", go ahead!
The Pharo 6 sources contain about 5800 classes and
over 40000 ifTrue:/ifFalse:/ifNil:/ifNotNil: uses.
The Dolphin core contains about 2100 clases and
over 12600 ifs.
My Smalltalk has about 13 ifs per class.
Smalltalk/X (JV) has about 6500 classes and
over 127000 ifs, nearly 20 per class.
��