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

[Helge Hess]

On 01.02.2004, at 07:49, Richard Frith-Macdonald wrote:
> 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.

I think everybody understood your point on that, but no one shares it 
;-) There is no Obj-C standard and the GCC implementation is *the* 
reference implementation we are talking about.
Besides that, I can see no viable reason for restricting bool in the 
way you do. It just doesn't buy you anything except trouble!

Note: nevertheless I still think that called code *should* return YES 
or NO to workaround such assumptions (be conservative and stable). And 
I also think that one *should* use YES when assigning to a BOOL 
variable.
Actually the latter case is in my opinion the reason why YES|NO was 
invented - to have a common value for expression BOOL (which is 
arbitary and non-exclusive).

> I hope it's clear that I think a BOOL must only take YES or NO values 
> and
> that anything else is 'dubious'.

Yes, I think it is clear what you think. But show me a person which 
shares your opinion ;-)

> 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 ...

Thats nonsense. The "if" statement takes a value and this is either 
true or false where true is defined as anything not null in C. The
  if (success) {}
is no less readable than
  if (success == YES) {}
indeed it is at least as readble (less text and 'if' shows the 
intention) and:
a) far more compatible with the rest of C
b) *far* less error prone (ever typed succes=YES? or !success==NO?) 
probably!
c) you are actually merging BOOL layers (because == YES resolved to a 
plain C
   bool - wicked!!)

> 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 ...

This certainly does *not* make for safer code, quite the contrary. It 
adds an *additional* boolean check (first the "== YES", then the 
"if()") and therefore your failure rate on boolean comparisons is going 
to be multiplied by two.

> I think common usage is
> if (boolean == YES) do_main_processing

I can't believe that you consider that good, because its doing the same 
thing twice. "if(boolean)" already checks for a boolean condition.

> 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.

In case the Cocoa Foundation does that as well - which I'm pretty sure 
it doesn't (didn't check) - I think this would be reasonable. In case 
it doesn't - hopefully this is enough to convince you (retaining 
compatibility).

> 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 still don't understand what this buys you. And anyway - even in case 
this would be implemented in the Objective-C language - the result 
would still be:
  if (boolean)
and would *never* require a
  if (boolean==YES)
!
If BOOL was implemented as YES|NO in the language this would only 
ensure that this is valid:
  BOOL boolean = 5;
  if (boolean == YES) // yup!
(the C boolean value '5' would be 'narrowed down' to an ObjC 'YES').

See: even with BOOL supported by the compiler, this would not change 
anything wrt the condition check.

> I guess I've been influenced by Java ... it does get some things right.

Obviously ;-) But I can hardly believe that a lot of Java developers 
actually write:
  if (condition == true)

(in German we say "doppelt gemoppelt", don't know whether there is an 
English translation for that ;-)

> Warnigns about loss of precision in assignments have certainly helped 
> me to find bugs.

And I've walked around enough bugs which resulted from people who fight 
the C language instead of writing in it. That null is false and 
anything else is true is a simple and useful rule.

Please rewrite Foundation in Java in case you want to have such funny 
bool stuff - well, actually I would recommend C++ or Eiffel - this 
seems to fit better.
That is exactly the same category like
  public static void myMethod(String blah) throws ExcA, ExcB, ExcC;
Bloat.

regards,
  Helge
--
http://docs.opengroupware.org/Members/helge
OpenGroupware.org