ifTrue: ~~ ifNil:

Andrew C. Greenberg werdna at gate.net
Wed Apr 12 23:50:08 UTC 2000


>I just put the question for the sake of the completeness of the 
>argument. It seemed odd to me that true ifFalse: [^#result] was nil, 
>when true ifNil: [^#result] was true. At first sight, I felt both 
>should be either nil xor anObject.

As folks noted, ifNil:,ifNotNil: does not serve the same purpose as 
ifTrue:,ifFalse.  Accordingly, the cry for "consistency" between the 
two structure pairs seems to miss the point.  The domain for the 
method-sets are entirely different, the class of all Objects for the 
former, the class of Booleans for the latter.

In short, if we are calling for the answer to

	X ifNil: [foo]

to parallel

	X ifFalse: [foo],

when X is true, why not also require the same parallelism of answers 
when X = 3 (or any other non-boolean, non-nil)?  I can see clear 
benefits to having the defaults for the one-legged values defaulting 
as they do (this was argued at length a few months ago), but see 
little benefit to adhering to a false consistency.
-- 
Andrew C. Greenberg		acg at netwolves.com
V.P. Eng., R&D, 		813.885.2779 (office)
Netwolves Corporation		813.885.2380 (facsimile)
www.netwolves.com





More information about the Squeak-dev mailing list