I read these values out of a database, where the reqtype (and reqstatus) are integers.
Hence, the variable "type" given reqtype, above. So, here, conceptually, is what I'm trying to do (in fact I tried this literally and it doesn't work). Note what I'm trying to use as the constructor in the request constructor:
How does one do this, short of using a switch statement?
You can give your enum class a static method which, given a type, returns a value of that type. Have the constructor add each enum value, as it's constructed, to a map; then have this static just look up the object in the map.
Have the constructor add each enum value, as it's constructed, to a map;
The map idea is good although I guess you meant static map. Also be aware that (from the JLS): "It is a compile-time error to reference a non-constant (�15.28) static field of an enum type from its constructors..." The workaround is to use instead a static method in the enum ctor.
I thank you genelemen. I see what you both have done. I think the map solution is better suited to larger enums, while, for what I'm doing, less than 10 or so values, the loop (which is basically a linear search vs. whatever the map uses [b-tree?]) is more appropriate. I think that's the fundamental difference. Agree?
One thing I didn't understand is what that quote from the spec about the "non-constant field" means.
There's really no need for either a map or a linear search here - an enum already has everything you need, built in. Every enum value automatically has an associated integer, called the ordinal. The first listed enum value has ordinal 0, the second is 1, etc. Conventiently, this is exactly the same set of values Allen is explicitly setting up with the constructor and the "type" field. It's unnecessary, since this is built into all enum types. The reqtype code can be replaced with:
That's it. The type() and valueOf() methods are so simple that you may chose to omit them - callers could do the same thing just as easily. However it seems that the uses of the ordinal() and values() methods are not widely known among programmers yet, so including the methods explicitly here may help usability.
I wrote my answer assuming the integer values could be different from the ordinal value, since he was using a member to store it. But an equally valid assumption is that he just didn't know about this machinery.
As far as the "static map" explanation.... umm, yeah.
Yeah, my answer assumes that the legal type values used in the DB will be 0, 1, 2, 3, etc. If that's the case, great. If not, yes it would be preferable/necessary to have a separate field in the code, as originally shown, agreed.
Also, I'd just use a HashMap like EFH suggested, as it's simplest to code and scales well. If by some chance there's really a need to optimize the lookup for better performance (highly unlikely since the database access will almost always be much slower than the HashMap lookup) - well I suppose I'd just code up a switch statement or array lookup, as either wil most likely be faster than either linear search or HashMap lookup under most circumstances. Such things aren't usually worth worrying about until you have a demonstrable case where a method is creating a performance problem. [ September 23, 2006: Message edited by: Jim Yingst ]
Yep, got it, and I really appreciate the information. I was aware of the ordinal facility, and, although it is set up that way now, didn't want to preclude negative values for anomalous events, etc. In fact, I wrote it a couple of days ago and only just yesterday added the unknown(0), which is what made it map so exactly to the ordinal function.
Now, to post my next question;0)
-------<br />Thanks & regards,<br />anw
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop