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