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