Greg Stein <gstein@lyra.org> writes:
> * a TON of property stuff. kinds, catgorization, prefixes, names, entry
> attributes(!) : what is this stuff in here for? answer: because
> svn_types.h is the least common denominator. the kitchen sink. these
> aren't types, but definitions. and they aren't globally useful. for the
> most part, they are client/WC things.
>
> * keyword definitions : similar to props
>
> * svn_log_message_receiver_t : a type, so "okay", but it really is kind of
> from left field.
>
> * SVN_STREAM_CHUNK_SIZE : decent, but more of an svn_defs.h kind of thing
>
> Anyhow, with the diff thing, I see that more as a function of svn_io.h or a
> higher-level svn_subr.h type thing. But svn_types? nah...
Heh. Well, I think the svn_diff_cmd_t would/should get the same
comment you made about svn_log_message_receiver_t:
> * svn_log_message_receiver_t : a type, so "okay", but it really is kind of
> from left field.
... but svn_diff_cmd_t is also mainly a client/WC thing, as per your
comments on the property stuff.
In general, it seems that header files always end up posing a few
weird categorization problems. C is a programming language, not an
ontology system. Of our existing headers, I can't think of any that's
more appropriate for svn_diff_cmd_t than svn_types.h. If we *were*
going to create a new header, I'm not sure what else it would hold
besides svn_diff_cmd_t, or if it did hold other stuff as well, I don't
see how we would avoid still feeling that something had been
miscategorized. :-)
All that said, if you can think of a new header that makes more sense,
by all means create it. I agree svn_types.h is a bit of a grab bag,
it's just that no better dividing line is jumping out at me right
now... "svn_subr.h" is pretty non-specific, and an abstract function
type isn't even really a subr anyway, if we're being picky.
Meanwhile, svn_io.h is about io, diff stuff seems as out-of-place
there as anywhere.
Maybe we should just wallow in a permanent state of sin and have
"svn-grab-bag.h"?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:09 2006