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

[Kazunobu Kuriyama]

David Ayers wrote:

<snip>

> Kazunobu Kuriyama wrote:
>
> > Apart from their being actually clever or not, it's responsibility for
> > Objective C how to define BOOL.  The fault lies only in the fact that 
> > BOOL
> > has not been made a built-in Objective C type so far (the spec 
> > defines it
> > as if it were, not explicitly stated like this though).  Without having
> > compilers exactly know the meaning of boolean, what can we expect 
> > them to
> > do with it?  They are only told BOOL is a kind of short integer!  Wrong
> > usage of BOOL must attribute to careless ObjC programmers, neither C
> > programmers nor compilers.  IOW, that's our problem.
>
>
> I'd say uninformed rather than careless, but maybe some sane C 
> programmer can offer a patch to our coding conventions to educate us 
> carelessly insane ObjC developers, by correctly and clearly stating 
> and demonstrating the issue. 

Broadly speaking, the conception of ObjC I have is based on:

(1) ... The Objective-C language is fully compatible with ANSI standard 
C. ...
  (Chapter 2, Apple's ObjC manual)
(2) ... Fun, of course, can also lead to danger.  And there is plenty to 
beware of
   with Objective-C.  Since Objective-C doesn't try to imporve the C 
language, you
   have to deal with all the faults and caveats of C.  In addition, the 
philosophy of
   Objective-C is to allow for great deal of flexibility, leaving the 
programmer to
   watch out for potential problems rather than forcing various 
restrictions....
  ("Objective-C is Fun", Adam Fedor)

Accordingly, your comments, including ones I snipped, looked a little bit
strange to me.  I thought all the above was taken for granted in the
community and that ObjC was as such.  If my wording sounded unnecessarily
offensive, it was not my intention.  But, remember, I didn't use the words
sane and insane against ObjC developers, but hypothetical C programmers.

> I'd appreciate if we could get back to the discussion on whether we 
> should have a public macro to warn/assert about the correct values of 
> BOOL parameters and return values, so that other carelessly insane 
> developers may be educated.
>
> I have no objections to stick with isYES(), but maybe a simple 
> is()/_is() may be less bulky than my previous alternatives and won't 
> be as hard to parse in comparisons involving NO.  I'd be in favor of 
> emitting a warning and "BOOLifying*" by default and possibly raising 
> with NDEBUG defined (i.e. when compiled with debug=yes).  If some 
> think this is too harsh because there are too many carelessly insane 
> developers that have produced legacy code that doesn't take care to 
> convert, I'd be fine with only emitting warnings. 


If we interpret the expression
   [NSNumber numberWithBool: (i=256)]; => NO
based only on the syntax compilers accept, we see it gives an expected,
natural result.

But once we impose our semantics on the same expression, it looks as if
it gave something unnatural.

Hence, the same expression gives rise to two possible different
interpretations, depending on which view we take.

So I'm wondering if changing the expression to
  [NSNumber numberWithBool: isYES(i=256)];
or something like this always gives the right answer.  Sometimes it is, but
what if generating NO is the coder's genuine intention?

If we have to pay attention to semantics defined by ourselves as well as
syntax, I'm afraid it makes the maintenance of code harder because we have
to take two possible interpretations into consideration and decide which is
the coder's intention.  Furthermore, it unexpectedly reduces the readability
of code when semantics and syntax respectively give contradictory
interpretations.

In addition, if we definitely need isYES(), I feel it should cover the
conversion rules C99's _Bool has.  Otherwise, I'm afraid we introduce
ANSI-incompatiblity to code.

Can the proposed macro address the problems mentioned above?  If so,
the macro seems OK to me.

Cheers,
- Kazunobu Kuriyama