Cascading messages.

Hi all,

I'm having fun with cascading messages.. Shouldn't those two have the
same result?

x := true.

"first version:"
(x) ifTrue: [x := false ].
(x) ifFalse: [x := true].
Transcript show: (x asString); cr.

"second version:"
(x) ifTrue: [x := false ];ifFalse: [x := true].
Transcript show: (x asString); cr.



The first version is constant true,  just as expected. If x is true, it
becomes false after the first message, then true again after the second
message, and is then show:n at the Transcript. If it is false to begin
with, the first message is ignored, and x becomes true after the second
message.

The second version using ; however, acts as a switch for some reason. I
was thinking that cascading using ; is only a shortcut, but that
doesn't seem to be the case. So where does this behaviour come from? Is
x copied into a temp variable of some kind if cascading is used, or am
I missing something stupid here :)


the asString message is my own, but there shouldn't be a problem here.
I didn't find anything fitting to convert Boolean, or Number to String.
Did I just miss those?

Matthias,

> I'm having fun with cascading messages.

Cascades are nice ;-)


I don't think so.  In the first form the expression (x) is clearly evaluated
twice, in the second it is evaluated only once.  The second form is supposed to
be equivalent to:

    tmp = x.
    tmp ifTrue: [x := false ].
    tmp ifFalse: [x := true].

so only one of the two possible assignments can happen no matter what the
initial value of x.  It makes a lot more sense when you remember that (x) might
be replaced by a complicated expression with lots of side-effects.


> I didn't find anything fitting to convert Boolean, or Number to String.
> Did I just miss those?

Look into #printString and #displayString (which are, as it happens, the same
for Integers and Booleans, but are different in general).  They are defined
against Object but many classes override one or the other (or both).

    -- chris

I wrote:

> Look into #printString and #displayString [...]  They are
> defined against Object but many classes override one or the other (or
> both).

More accurately, classes typically override #printOn: and/or #displayOn: which
has the same effect but is more general.

    -- chris

Chris Uppal schrieb:


Thanks for clearing that one. It does indeed make more sense this way.
I noticed this when I was trying to find an example where
ifTrue:ifFalse gives a different result than ifTrue: ; ifFalse: With
the receiver copied into a tmp variable, I would say such an example
doesn't exist.

>
> > I didn't find anything fitting to convert Boolean, or Number to String.
> > Did I just miss those?
>
> Look into #printString and #displayString (which are, as it happens, the same
> for Integers and Booleans, but are different in general).  They are defined
> against Object but many classes override one or the other (or both).

...now that you mention it I'm really sure that was teached in the
tutorial too...