[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: |
Tue, 3 Feb 2004 01:39:18 +0100 |
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
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), (continued)
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), David Ayers, 2004/02/02
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Richard Frith-Macdonald, 2004/02/02
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Richard Frith-Macdonald, 2004/02/02
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Helge Hess, 2004/02/02
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Nicola Pero, 2004/02/02
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Pascal J . Bourguignon, 2004/02/02
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Helge Hess, 2004/02/02
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Pascal J . Bourguignon, 2004/02/03
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Pascal J . Bourguignon, 2004/02/03
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Richard Frith-Macdonald, 2004/02/02
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?),
Helge Hess <=
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Pascal J . Bourguignon, 2004/02/02
Re: Re[2]: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Helge Hess, 2004/02/01
Re: Re[2]: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Helge Hess, 2004/02/01
Re: Re[2]: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Helge Hess, 2004/02/01