Re: [RFA]: BOOL coding standards (Was: Problem with+numberWithBool: ?)

[Richard Frith-Macdonald]

On 1 Feb 2004, at 03:05, Alexander Malmberg wrote:

> Richard Frith-Macdonald wrote:
> > On 30 Jan 2004, at 16:00, Alexander Malmberg wrote:
> > > I've attached a patch to our coding standards. OK to commit? If so, 
> > > new
> > > code will work ok, and I'll get to work on patching core/ (hopefully
> > > with some help from David Ayers :).
> >
> > Predictably perhaps,  I don't really like it ...
> >
> > I think the idea a boolean type is an improvement over C,
>
> But BOOL isn't a boolean type. _Bool is.

I'm obviously not making myself clear.
I believe that BOOL was intended to be a true boolean type, and that 
the reason
that it is not implemented as such is purely a historical one in that 
the compiler
did not support it at the time.  It seems clear to me that the in the 
Objective-C
language, BOOL is a boolean, and the compiler does not fully implement 
the
language, so we have to work around this implementation detail in the 
compiler.

> > and it worries
> > me that being too tolerant will encourage bad coding (and may make
> > the code less readable).
>
> This is interesting, because I see these two faults in your preferred
> way of doing this: bad code because it doesn't handle truth values
> correctly, and less readable because it clutters the code with
> unnecessary comparisons. The latter is just a style issue, so I don't
> care much about it, but the former is a correctness issue, as far as 
> I'm
> concerned.
>
> As it turns out, this isn't as obvious as I thought it'd be. Thus, we
> should decide which it is and clearly document it in the coding
> guidelines. Either booleans are normal c truth values, or booleans may
> only have the values YES (1) or NO (0).

I hope it's clear that I think a BOOL must only take YES or NO values 
and
that anything else is 'dubious' .  I think that testing for equality 
with YES
makes it clear what we are doing, and has the advantage of ensuring that
'dubious' values cause the alternative codepath to be taken ... ie the 
method
returning the non-YES/NO value is treated as having returned a NO, and
(generally) as having failed.  This makes for safer code ... it's not 
nearly
as good as a runtime test for a YES/NO value which raises an exception
or logs the problem, but it's very quick and easy.
eg. I think common usage is
if (boolean == YES) do_main_processing
else handle_error_or_problem
In retrospect, in the light of your comments etc, I see that doing this 
is not
obvious and I should have been adding the clutter of a macro to raise an
exception ... though you don't like that either.

If we want to mandate a standard way of testing the results of an
> > operation
> > which is supposed to return a BOOL, perhaps use of a macro might be
> > better.
> > eg.
> >
> > if (IsYes([receiver aMessage])) ...
>
> Please, no! This is even worse clutter.

My ideal would be if the compiler treated BOOL as a true boolean, and 
if it
warned about assigning possible non boolean values to a BOOL without
a cast.  This would remove the runtime checking issues.  Is there a 
flag to
ask gcc to warn about possible loss of data when assigning a larger 
expression
to an lvalue of a smaller type?

I guess I've been influenced by Java ... it does get some things right. 
 Warnigns
about loss of precision in assignments have certainly helped me to find 
bugs.