BOOLEAN as enum

P E Smee exspes at
Thu Apr 12 18:58:50 AEST 1990

In article <1990Apr6.230447.22818 at aqdata.uucp> sullivan at aqdata.uucp (Michael T. Sullivan) writes:
>:From article <1990Apr6.102819.9379 at>, by exspes at (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 - ..!uunet!ukc!bsmail!p.smee - Tel +44 272 303132

More information about the Comp.lang.c mailing list