Subject: Re: why properties are strings instead of enums
From: Mike Nordell (tamlin@algonet.se)
Date: Thu Jan 25 2001 - 20:07:46 CST
Aaron Lehmann wrote:
[enums]
> Also, you tend to catch more errors (like typos) at compile time when
> using enums.
>
> The only problem I see with enums is that they have to be prefixed.
> TEXT is definately too ambiguous and conflict with something else in
> the source tree. It would have to be FMT_RunType_TEXT or something.
> This is not so with strings.
Since we don't (currently) support namespaces, what about putting them in an
(empty?) class? Or probably better yet, in the class which produces them.
That way they're in "namespace" (i.e. the class) and can be used by "::"
qualification. Sure, xxx::RunType is explicit, but is it overly explicit?
One could argue that the class name qualification is a "prefix whart", but I
don't think it is since the prefix is a type, not a text-substitution.
> But both are minor issues of programmer convenience. Enums should be
> adopted becuase of their speed and elegance as compared to strings.
Agreed. But, it's still (in my mind) that matter of type-safety. However
convenient a string is, it's about as type safe as a void* and it's *very*
costly in CPU cycles compared to an enum. An enum immediately express the
intention, making the code much more readable. If we need a "const char*"
overload for properties we haven't invented just yet I'm all for it, but I'd
still like to see the enum approach for the known values.
/Mike - please don't cc
This archive was generated by hypermail 2b25 : Thu Jan 25 2001 - 20:08:37 CST