On Wed, 27 Jun 2007 00:02:46 -0700, Andreas Raab andreas.raab@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===