Re: Dynamic enums
On 10/12/2011 2:02 AM, Linus Flustillbe wrote:
On 2011-10-12, Eric Sosman<esosman@ieee-dot-org.invalid> wrote:
On 10/11/2011 10:05 PM, Eric Sosman wrote:
[...]
No. The names of enum constants are compile-time artifacts,
just like the names of local variables. At run-time, all such
things have disappeared (well, they may survive in ancillary debug
data, but the C language has no access to such things).
Oh, ratzafratz: I forgot which newsgroup I was in. The *Java*
language has access to this sort of information via reflection.
Still, the information is very nearly read-only, and reflection
can't inject a new enum into the mix. (Java can, of course, load
a new .class with a new definition for the enum -- but that just
introduces a different enum class that happens to have the same
name, under the scope of a different classloader.)
So basically the answer is "no" which is what I thought. Glad to have
caught this early. Here's a good question for you...
I'm using (for now) an ArrayList<lookup_type_object>() to store my
lookup objects. This seemed like the best vehicle and iteration was as
easy as looking in the API docs. Is there a better vehicle for storing
an indeterminate number of *objects* which allows for easy addition,
removal and iteration?
List is good if the order of the objects is important, so
{A,B,C} and {C,A,B} have different significance. Set is good if
order is irrelevant, so {A,B,C} and {C,A,B} have the same meaning.
Note that Set forbids duplicate elements: {A,B} is possible but
{A,B,B} is not. If you need the latter (a "multiset") there's no
ready-built solution in java.util (unless they've added something
recently), but you can use a Map with A,B,... as keys and their
occurrence counts as values.
List, Set, and Map are interfaces, not classes. Java provides
several implementing classes for each interface, with different
characteristics and special features. For example, List is implemented
by ArrayList, LinkedList, Vector (not used much any more) Stack, and
still more special-purpose classes -- and you can add your own if you
have needs that Java's implementors didn't anticipate. The same goes
for the other interfaces: Java provides a handful of ready-made classes,
and you can write your own at need.
Stepping back a bit, it's not clear to me why you need a separate
data structure just to hold the keys. In your original post you wrote
of pairings in "a table called foobar," matching A with 1, B with 2,
and so forth. This sounds very much like a Map with entries {A,1},
{B,2} and so on, or possibly a List {A,B,...} where the "value" is the
key's position in the list. Either way, I see no obvious reason to
maintain an extra data structure to duplicate information the primary
structure already possesses.
--
Eric Sosman
esosman@ieee-dot-org.invalid