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

[David Ayers]

Philippe C.D. Robert wrote:

> The only reasons I can find are compatibility with existing source 
> code and compatibility with C truth values which are IMO both weak 
> arguments in this context (if at all), as they are not explaining the 
> real need or justification for such a construct. Did I miss something 
> else?


The compatibility with C truth values is the important reason.  The 
compatibility with OPENSTEP / OS X is secondary but would be sufficient 
in my view.

I believe we all agree that methods returning a BOOL should return 
either YES or NO.

I guess I could be persuaded to allow test of '== YES' against the 
return values of such methods to be valid, even though that is a painful 
compromise and leaves an aftertaste of potential loss of robustness 
without any technical gain (aside from minor readability issues in 
obscure cases that don't warrant the loss of potential robustness).  
I'll probably keep a local patch for production code that simply 
eliminates those tests which  has the (probably unmeasurable) side 
effect of being faster and I lose nothing.

Yet I strongly believe that relying on/asserting YES/NO values on BOOL 
parameters is wrong and that C truth values should be accepted and 
transformed to YES/NO in a robust manner.
(I won't try to veto warnings as long as they're NSDebugLLog or at least 
NSWarnLog, even though I feel they shouldn't exist at all.  Others may 
:-) ) 

I'm not sure whether using _Bool may invalidate all archives using 
@encode (read .gorm/.nib files).  I'm not going to look into it any 
deeper but if someone feels lucky they could just try changing it in 
objc/objc.h, bootstrap the compiler and recompile everything from 
scratch.  Realistically such a change can only be made in a potential 
unified ObjC Runtime and even then I'm uncertain whether Apple will 
change the definition of BOOL, if they loose binary 
compatibility/invalidate .nib files.

Yet such a change seems overkill, since all we have to do is find a 
replacement for "== YES" test.  I must admit I'm a bit surprised by the 
amount of reservations this has brought up. This is a technical issue 
vs. style / readability issue.

If using strict semantics uncovered bugs, then the question is, how 
should they be fixed.  Must the callers guarantee to provide YES/NO or 
must the callee interpret C truth values.  In the quoted examples I have 
yet to find a case in OPENSTEP / OS X where the burden is on the caller.

Cheers,
David

BTW: On OPENSTEP Enterprise 4.2
[[NSDecimalNumber numberWithFloat: 3.3] boolValue]
returns 3.
A clear case where the assumption that methods returning BOOL must 
return YES/NO is broken.  I guess could make an exception on 
'-boolValue' in particular as it is documented to misbehave and also 
misbehaves in practice.  It would be interesting to know whether this 
has been fixed in Cocoa.

/me wonders whether he should revert his acceptance of '== YES' against 
methods which return BOOL... (but will definitely maintain his local 
s/==YES//g patch.)