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

[Alexander Malmberg]

David Ayers wrote:
[snip]
> The macro isYES() originally was meant as a
> replacement for "== YES" to allow all non NO values to interpreted as YES.

It was also meant to be customizable so that those who wanted a warning
could use one definition, those who wanted an assertion another, and
those who just wanted the code to shut up and work a third.

[snip]
> Therefore [NSNumber numberWithBool: isupper(c)] is unsafe code.

If the intent is the obvious one, yes. So don't do that, then.

If you're unsure about what your c code really means, it's certainly a
good idea to be careful about generating BOOL values, and to use only
YES and NO. I don't even see anyone arguing that this shouldn't be in
the coding standard for GNUstep (something like "Code that produces BOOL
values must produce only the values YES (1) and NO (0).").

However, from that it definitely does not follow that you should force
this style on everyone using GNUstep by being pedantic about which
values should be accepted.

Again, the isYES() macro was meant to have several definitions so that
developers with different opinions would still be able to use -base. You
would already have been able to use a definition that used an assertion,
so your suggestion here seems to boil down to removing my choice of
using another definition. I do not think that is acceptable.

- Alexander Malmberg