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/