BOOLEAN as enum

[P E Smee]

In article <1990Apr6.230447.22818 at aqdata.uucp> sullivan at aqdata.uucp (Michael T. Sullivan) writes:
>:From article <1990Apr6.102819.9379 at bath.ac.uk>, by exspes at bath.ac.uk (P E Smee):
>> Depends on what you're writing.  I frequently find it appropriate to
>> have THREE possible answers to a yes-or-no function.  Loosely described
>> as 'TRUE', 'FALSE', and 'I don't know'.
>
>If there are three answers, then it isn't a TRUE/FALSE question so
>the names "TRUE" and "FALSE" shouldn't be used.  
>If there are more answers then pick other names.

I think we're becoming theological here.  I understand your position,
and can see the rationale behind it.  On the other hand, my viewpoint
is that for most useful TRUE/FALSE questions, there is actually a third
possible 'answer' which loosely speaking translates as 'I'm not able to
determine which is the case'.  Maybe because of incomplete data; maybe
because of a hardware limitation; maybe because you've given me invalid
arguments.  And so on.

That is, the question is actually a TRUE/FALSE question, but there is
some probability that it will be (in some contexts) 'unanswerable' or
indeterminate.  Adding a third return value provides a handy way of
handling these cases.  (I see it, in some sense, as analogous to IEEE
NaN's for floating point.  Though the analogy is a bit weak since my
'Can't tell' value is not automagically supported by the hardware.)

As I said elsewhere, though, what mostly concerns me is that any given
chunk of code is written consistently -- just in case I have to take it
over.  If you prefer tri-state 'two-states' (I do) then fine, use them.
If you don't like them, use some other method of exception handling.
Please don't mix them haphazardly.

-- 
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
 P.Smee at bristol.ac.uk - ..!uunet!ukc!bsmail!p.smee - Tel +44 272 303132