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
|