[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN type concerns

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2001-02-22 20:44:51 CET

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.)

Received on Sat Oct 21 14:36:23 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.