[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFA]: BOOL coding standards (Was: Problem with+numberWithBool: ?)
From: |
Helge Hess |
Subject: |
Re: [RFA]: BOOL coding standards (Was: Problem with+numberWithBool: ?) |
Date: |
Mon, 2 Feb 2004 02:01:49 +0100 |
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
Re: [RFA]: BOOL coding standards (Was: Problem with+numberWithBool:?), Alexander Malmberg, 2004/02/02