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>
wrote:
> 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
written:
^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.
===Blake===
More information about the Squeak-dev
mailing list
|