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
|