"Richard A. O'Keefe" <ok at atlas.otago.ac.nz> wrote:

> 
> 	Side note, I don't like returning *whatever* the last item is, especially
> 	if it's not a boolean (the way lisp does). In the ANSI spec, the return
> 	value of #&/#| is supposed to be defined by the respective truth
> 	tables. Afaik, true and false are the only truth values in Smalltalk (the
> 	other objects do *not* have a Boolean interpretation) which suggests that
> 	true | 4 should be an error. Of course, IIRC, the ANSI spec sorta leaves
> 	this situation undefined, so I guess returning anything is kosher.
> 	
> It's really a speed/safety tradeoff.  Do you want every and: and or: in
> the Smalltalk universe to run slower to catch type errors that don't really
> seem to be a problem?



It's not that simple.  Besides speed and safety, all extra code means
extra code to maintain and an extra chance to smake a mistake.  In fact,
I'd guess that extra checks like this don't tend to get tested very
hard, and so it's easier for errors to slip through.

Many times, the fastest way to see whether an operation makes sense is
to try it and see what happens.  It's hard for me to imagine someone
using & in a situation where both the first argument is *never* false
and where the result of the & isn't actually checked.  Almost always
it's something like:

	(..a...) & (..b...) ifTrue: [... ].

So the ifTrue: will catch the error if you ever run a test case with
(..a..) being false.

Okay, so this is a mountain out of a 5-token  molehill.  But I wanted to
defend the general principle, and say *don't* add explicit type
checks!--


-Lex