What to believe?
Blake
blake at kingdomrpg.com
Tue Jun 26 21:59:17 UTC 2007
On Tue, 26 Jun 2007 14:00:36 -0700, Jon Hylands <jon at huv.com> wrote:
> On Tue, 26 Jun 2007 13:45:22 -0700, Blake <blake at kingdomrpg.com> wrote:
>
>> The latter strikes me as silly. In a language where "if" is part of the
>> grammar, I can see it sort-of making sense, especially if nesting "if"s,
>> to include "else"s with NOPs.
>
> The issue is, what does the expression return, in the false case, if
> #ifFalse: isn't there?
>
> It may be a Smalltalk standard to return nil in that case - I have no
> idea. Personally, when I'm doing something with an expression (like
> returning it, or assigning it), I always make it very explicit what I
> (the programmer)
> expect to happen in all cases...
Good point. I didn't note the ^ at the beginning and was just looking at
the statment.
However, is the question not really "What do the booleans return from an
if* statement if the conditional is not met"? In which case, the answer is
"nil".
Which, perhaps inevitably, leads me back to my original conclusion: It's
silly. "if" is not a language construct with undefined and potentially
ambiguous results. It's a set of messages sent to a class. It's kind of
like all those languages that use "for" loops in which the control
variable is undefined after the loop. Lint tools will warn you about using
that control variable; that would just be silly in Smalltalk.
I guess if we're talking portability though, it might be a valid question.
I'm not sure the Smalltalk spec mandates that instances of True and False
must return nil. But what else =would= they return? Self?
===Blake===
More information about the Squeak-dev
mailing list
|