What to believe?

Blake blake at kingdomrpg.com
Wed Jun 27 07:26:55 UTC 2007

On Wed, 27 Jun 2007 00:02:46 -0700, Andreas Raab <andreas.raab at gmx.de>  

> 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")

Given that we're off in alternate realities, this probably isn't that  
important but wouldn't the above require a lot of code like this to be  

^someTest ifTrue:[someObject] ifFalse: [nil].

because otherwise the return value will be a valid non-nil object that  
must be tested for. In other words, unless you set the result to nil  
specifically, clients of the code must be prepared to handle a valid  
object, nil (as now), and a boolean. And they must have awareness of the  
fact that sometimes True means nil and sometimes False means nil (or I  
guess that a boolean means nil). And then what if the non-nil block  
returns a boolean?

Not that such would be insurmountable, but it seems like the approach as  
implemented is cleaner.


More information about the Squeak-dev mailing list