What to believe?

Bert Freudenberg bert at freudenbergs.de
Wed Jun 27 07:24:16 UTC 2007


On Jun 27, 2007, at 9:02 , Andreas Raab wrote:

> Bert Freudenberg wrote:
>>> I guess if we're talking portability though, it might be a valid  
>>> question. I'm not sure the Smalltalk spec mandates that instances  
>>> of True and False must return nil.
>> "ifTrue: aBlock" is short-hand for "ifTrue: trueBlock ifFalse:  
>> []". The value of an empty block is nil by definition. That's why  
>> True and False must return nil in #ifFalse: and #ifTrue:,  
>> respectively.
>
> That is not necessarily the case. One can make an equally good  
> argument saying that "foo ifTrue:[...]" should expand to "foo  
> ifTrue:[...] ifFalse:[foo]" which is coincidentally true for  
> ifNil:ifNotNil: and *should* be true (and I'm glad we fixed this in  
> Croquet) for ifEmpty:ifNotEmpty:. In other words if it is the case  
> that:
>
>   42 ifNil:[...] => 42
>   #(1 2 3) ifEmpty:[...] => #(1 2 3)
>
> then it seems quite consistent to have
>
>   false ifTrue:[...] => false.
>
> (not that I'm proposing to change this btw, since it would break a  
> whole bunch of stuff but it's perfectly consistent with other  
> semantics that are generally deemed "intuitive")

Granted. I understood the question to be about wether the behavior  
was arbitrary and Squeak-specific or actually specified and portable.  
I'd argue it's the latter, if only because ifTrue:/ifFalse: predates  
the other constructs by a large margin and all Smalltalk variants  
inherited that behavior.

- Bert -





More information about the Squeak-dev mailing list