Karl Fogel <kfogel@galois.collab.net> writes:
> Consistency in this relatively minor matter is not very important,
> IMHO not nearly important enough to require resolution or a vote or
> something. Let's just do this: Jim use ints, and we'll use
> svn_boolean_t's. A person tends to spend the most time reading their
> own code, so this works out well.
>
> Of course, if you have the sense that you're making changes in an area
> of code that is more or less "owned" by someone else, try to stick to
> their style. For example, if I were to edit node-rev.c, I wouldn't
> start using svn_boolean_t in code that otherwise uses int. But
> likewise, I'd expect to see svn_boolean_t in editor.c.
Oh, I'm sorry, my above proposal sidesteps the real issue: that there
are certain public interfaces which *return* an int to signify a
boolean result.
There I do think it's inconsistent that some Subversion libraries
return svn_boolean_t, and others return int. We should either decide
to get rid of svn_boolean_t entirely, or use it in the fs interfaces
just as we use it elsewhere.
(Either way would be a trivial change, and I'll certainly volunteer to
do it, whatever we decide.)
I'd like to hear others' thoughts on this. For what it's worth, I'm
+0 on getting rid of svn_boolean_t. It does give a readability bonus
imho, but it's not worth a whole new type.
(Yes, this could be seen as a reversal from something I argued
earlier, but if you point that out I'll ping flood you.)
-K
Received on Sat Oct 21 14:36:23 2006