You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2001/02/09 23:53:07 UTC
Re: CVS update: subversion/subversion/libsvn_delta delta.h xml_output.c xml_parse.c
On Fri, Feb 09, 2001 at 11:14:20PM -0000, cmpilato@tigris.org wrote:
> User: cmpilato
> Date: 01/02/09 15:14:20
>
> Modified: subversion/libsvn_delta delta.h xml_output.c xml_parse.c
> Log:
> * libsvn_delta/delta.h
>
> Added #defines for the various XML tag names and attribute names used by
> the xml parser and xml output routines in this module.
Note: some people may wonder why we should use a #define for a string
because every time we change the string, we gotta go rename the #define and
later the string anyways (e.g. extra work). Well, kiddies... you only have
to check for typos once with a #define; raw strings leads to all kinds of
nasty typos that are a hella-bitch to find. With #defines, you get
compilation errors instead.
> * libsvn_delta/xml-parse.c
> * libsvn_delta/xml-output.c
>
> Modified various functions to use the newly abstracted XML tag names and
> attribute names found in delta.h instead of explicitly referencing char
> strings.
>
> All of the above was done in anticipation of (yea, as a precursor
> to) a slew of editor interface changes that I'll soon be working on,
> which will inevitably result in changes to the XML DTD as well. Greg
> Stein, please put on your Namespace Protection Police cap and make
> sure that new brain I ordered this morning is working better than my
> old one.
hehe... looks fine to me. I'm simply interested in sharing what you were
smoking yesterday :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: CVS update: subversion/subversion/libsvn_delta delta.h xml_output.c xml_parse.c
Posted by Bob Miller <kb...@jogger-egg.com>.
Greg Stein wrote:
> > (And, pet peeve: i.e., not e.g..)
>
> I recall you giving the latin for them, but I forgot the meaning/purpose of
> each one. I'm obviously a bit fuzzy on which to use sometimes :-)
E.g. is latin for "Eggsample". I.e. is "Inoth Erwords" (i.e., "in
other words").
--
Bob Miller K<bob>
kbobsoft consulting
http://kbobsoft.com kbob@jogger-egg.com
Re: CVS update: subversion/subversion/libsvn_delta delta.h xml_output.c xml_parse.c
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Feb 09, 2001 at 07:00:27PM -0500, Greg Hudson wrote:
> > Note: some people may wonder why we should use a #define for a
> > string because every time we change the string, we gotta go rename
> > the #define and later the string anyways (e.g. extra work). Well,
> > kiddies... you only have to check for typos once with a #define; raw
> > strings leads to all kinds of nasty typos that are a hella-bitch to
> > find. With #defines, you get compilation errors instead.
>
> I still think the cost is higher than the benefit. With literal
> strings you can see what the thing is, right away. With a
> preprocessor symbol you don't even know it's a string.
>
> Are we going to do this every time we generate terminal output as well
> as every time we generate XML output?
Terminal output is different. It doesn't have to be consistent across the
codebase. For example, if I stored a WC prop named "activity-id" and then
later tried to look it up as "activity-ID", I'd be screwed. The symbol
prevents that.
The string-thing is a non-starter. It doesn't really matter what it is. If
you look at the prototype, then you know it is a string; if you look at the
macro, then you know. If you look at neither, then what's it matter? :-)
> (And, pet peeve: i.e., not e.g..)
I recall you giving the latin for them, but I forgot the meaning/purpose of
each one. I'm obviously a bit fuzzy on which to use sometimes :-)
> >> Greg Stein, please put on your Namespace Protection Police cap and
> >> make sure that new brain I ordered this morning is working better
> >> than my old one.
>
> > hehe... looks fine to me. I'm simply interested in sharing what you
> > were smoking yesterday :-)
>
> These aren't public symbols. They don't need such annoyingly long names.
This is true.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/