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

[Helge Hess]

On 02.02.2004, at 20:43, Richard Frith-Macdonald wrote:
> > We are not talking about return values!
> I don't think you and I are talking about the same things.

Hu? I'm talking about the issue which AFAIK started the thread and this 
is about *input* parameters:
---snip---
+numberWithBool: is defined as:

        + (NSNumber*) numberWithBool: (BOOL)value
        {
          if (value == YES)
            {
              return boolY;
            }
          else
            {
              return boolN;
            }
        }

So as far as I understand [NSNumber numberWIthBool:2] will return boolN 
which is wrong as 2 is TRUE, isn't it ? (Or may
I need some sleep ? :-)
---snap---

This method has nothing to do with BOOL return values and even if some 
people do not consider it broken, this will break loads of code that 
assumes regular C semantics and is, btw, incompatible with Cocoa.

> >     NSLog(@"Hello, World!: %@", [NSNumber numberWithBool:5]);
> > gives
> >     2004-02-02 19:52:35.633 BoolTest[4187] Hello, World!: true
>
> Good idea ...  I tried a test more appropriate to the issue I've been 
> discussing  -

Well, then you have been discussing with yourself. I think there is no 
question on this.
My code demonstrates a SERIOUS incompatibility of GNUstep with Cocoa 
(and C in general).

>   NSLog(@"%d", [[NSNumber numberWithBool: 5] boolValue]);
> gives
>   2004-02-02 19:28:08.227 Test[1909] 1
>
> Which is what I would regard as the correct behavior of boolValue.

If this works that way on GNUstep, I'm fine. If the NSNumber code is 
implemented as shown by Manuel, it won't (because 5 won't evaluate to 
YES).

Anyway, we can agree on the thing "you were discussing" - methods 
declared BOOL should return either YES or NO. Nevertheless you need to 
fix the broken code which assumes only YES on *input* parameters.

a) I sign every statement which says: "a method returning a BOOL value 
should return exactly YES or NO".
b) I will not sign a statement which says: "a method expecting a BOOL 
value must get passed in YES for a truth value".

You were discussing a), fine, we agree. I never questioned that. I'm 
discussing b) - since this has practical value and will break code.

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