The motivating example can be written
aHasDot := a includes: $..
bHasDot := b includes: $..
^aHasDot = bHasDot
ifFalse: [bHasDot]
ifTrue: [aHasDot
ifTrue: [a < b]
ifFalse: [a > b]]
(Dijkstra was right. People *do* forget that '=' is
one of the standard Boolean operations, and it matters.)
This is absolutely straightforward, and without wasting
any time wondering what the three-headed IF monster is,
we can go straight to the big puzzle: "I can see at a
glance what this DOES, but what the heck does it MEAN?"
When would this be useful? What would be a good name for
this combination, however expressed?
I think the moral here is "when you have code whose
structure is so complex that you are tempted to construct
special control flow objects to make it LOOK simpler,
rewrite it so that it IS simpler."
I once wrote a class called Distributor based on Boost
'signal's. It was an interesting exercise, and I am
still finding mistakes in it. It was not entirely unlike
ComplexCondition. What I *haven't* done in the 10 years
since I wrote it is found any use for it.
On Wed, 16 Mar 2022 at 07:15, <s...@clipperadams.com> wrote:
> ComplexCondition as described in Andres Valloud, "A Mentoring Course on
> Smalltalk"
> <http://www.lulu.com/product/paperback/a-mentoring-course-on-smalltalk/3788890>
> is available at http://www.squeaksource.com/ComplexCondition.html
>
> With it, you can do something like:
>
> ^[a includes: $.], [b includes: $.]
> ifAllTrue: [a < b]
> ifAnyTrue: [b includes: $.]
> otherwise: [a > b]
>
>
