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

Re: CVS update: subversion/subversion/libsvn_delta delta.h xml_output.c xml_parse.c

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2001-02-12 16:10:22 CET

Greg Hudson <ghudson@MIT.EDU> writes:
> 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?

Yes, eventually, if we internationalize. :-)

> (And, pet peeve: i.e., not e.g..)

I.e., e.g. is for examples (e.g. "e.g."), whereas i.e. (i.e., "that
is") just means "that is" (e.g. "i.e.").

> These aren't public symbols. They don't need such annoyingly long names.

It's for any symbol that lives in a public namespace, whether
intentionally published or not. From HACKING:

   * Signify internal variables by two underscores after the prefix.
     That is, when a symbol must (for technical reasons) reside in the
     global namespace despite not being part of a published interface,
     then use two underscores following the module prefix. For

        svn_fs_get_rev_prop () /* Part of published API. */
        svn_fs__parse_props () /* For internal use only. */

Preprocessor symbols are of the latter type, right?

Received on Sat Oct 21 14:36:22 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.