Reconciling Enums and Lookup Tables
-
We all love to use enums instead of magic numbers, but what happens when the enums are based on a lookup table than can change? It seems like there's room here from some interesting dynamic code, possibly building the enum dynamically, but the conflict is with actual coding using the enum, as code can actually only use values present when the code is written, unless there is some even more outlandish way to use runt-time enum values.
I like using classes instead of enums these days.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway -
I was thinking more like Janet Jackson Nasty. :rolleyes:
:..::. Douglas H. Troy ::..
Bad Astronomy |VCF|wxWidgets|WTLDouglas Troy wrote:
I was thinking more like Janet Jackson Nasty.
hmmmm a flashing enum? I have never heard of one....
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Douglas Troy wrote:
I was thinking more like Janet Jackson Nasty.
hmmmm a flashing enum? I have never heard of one....
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
El Corazon wrote:
hmmmm a flashing enum? I have never heard of one....
here you go.
enum TrafficLightTypes { 1: Steady; 2: Flashing; }Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull
-
We all love to use enums instead of magic numbers, but what happens when the enums are based on a lookup table than can change? It seems like there's room here from some interesting dynamic code, possibly building the enum dynamically, but the conflict is with actual coding using the enum, as code can actually only use values present when the code is written, unless there is some even more outlandish way to use runt-time enum values.
In our case, we use a string representation of the
enumoutside the application (persistence in files, across communications, and so on). The numeric value doesn't matter in this case, and can change. There are some border cases you have to handle (when an enumeration value is removed), but it works fairly well. One thing the Ada programming language had going for it was all of this happened automatically with enumerated types.Software Zen:
delete this;
Fold With Us![^] -
We all love to use enums instead of magic numbers, but what happens when the enums are based on a lookup table than can change? It seems like there's room here from some interesting dynamic code, possibly building the enum dynamically, but the conflict is with actual coding using the enum, as code can actually only use values present when the code is written, unless there is some even more outlandish way to use runt-time enum values.
I use a helper class that I call
ValueMapwith static functions for retrieving data. It's sole purpose is to match strings to values by doing a lookup in a specialized database table. This way, I can use a string to describe the value I need, and let theValueMapclass translate it into a number for me. For example, in our application we deal a lot with two specific countries: USA and Canada. All the other countries are important, but aren't used as nearly much. So, if I need to know the database ID for Canada, I don't want to hardcode it into the application, but I still need to be able to reference it programatically. (For initializing combo boxes with a default country for example). What I have done is create a second table that contains mappings of strings to commonly used database ID's and default values.Property
Value
Country.CountryID.USA
75
Country.countryID.Canada
32
So, to find the database ID for Canada, I would do something like this:
int canadaID = ValueMap.GetValueInt32( "Country.CountryID.Canada" );Your ValueMap class can retrieve the values from the relevant storage (SQL server, XML files etc) and even cache them for faster subsequent retrieval. My own personal naming convention is[Table].[Column].[Value]as you can see in the example, but you can use whatever strings you like to identify the values. I'm sure there are probably better ways of doing this, but it's working fine for me. I hope it helps :)Sunrise Wallpaper Project | The StartPage Randomizer | The Windows Cheerleader
-
We all love to use enums instead of magic numbers, but what happens when the enums are based on a lookup table than can change? It seems like there's room here from some interesting dynamic code, possibly building the enum dynamically, but the conflict is with actual coding using the enum, as code can actually only use values present when the code is written, unless there is some even more outlandish way to use runt-time enum values.
Google comes up with Enums powered by Reflection[^] from some obscure developer site. :)
-
El Corazon wrote:
hmmmm a flashing enum? I have never heard of one....
here you go.
enum TrafficLightTypes { 1: Steady; 2: Flashing; }Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull
more like ... enum FlashingType { TrenchCoat, BathRobe, OpenBlouse, WardrobeMalfunction } :rolleyes:
:..::. Douglas H. Troy ::..
Bad Astronomy |VCF|wxWidgets|WTL -
We all love to use enums instead of magic numbers, but what happens when the enums are based on a lookup table than can change? It seems like there's room here from some interesting dynamic code, possibly building the enum dynamically, but the conflict is with actual coding using the enum, as code can actually only use values present when the code is written, unless there is some even more outlandish way to use runt-time enum values.
For one small application I have I chose to use a pair of static readonly dictionaries (
<int,string>and<string,int>) which I fill from the table when the app starts up. -
We all love to use enums instead of magic numbers, but what happens when the enums are based on a lookup table than can change? It seems like there's room here from some interesting dynamic code, possibly building the enum dynamically, but the conflict is with actual coding using the enum, as code can actually only use values present when the code is written, unless there is some even more outlandish way to use runt-time enum values.
Perhaps the table should be updated at runtime to reflect the contents of the enum rather than the other way around. That would have saved me some trouble yesterday... when somebody emptied one of my translation tables. :mad:
-
more like ... enum FlashingType { TrenchCoat, BathRobe, OpenBlouse, WardrobeMalfunction } :rolleyes:
:..::. Douglas H. Troy ::..
Bad Astronomy |VCF|wxWidgets|WTLNo Flags attribute?
-
Perhaps the table should be updated at runtime to reflect the contents of the enum rather than the other way around. That would have saved me some trouble yesterday... when somebody emptied one of my translation tables. :mad:
PIEBALDconsult wrote:
Perhaps the table should be updated at runtime to reflect the contents of the enum rather than the other way around.
I really like that idea, I'll just have to tighten up DB security to prevent direct inserts.
-
We all love to use enums instead of magic numbers, but what happens when the enums are based on a lookup table than can change? It seems like there's room here from some interesting dynamic code, possibly building the enum dynamically, but the conflict is with actual coding using the enum, as code can actually only use values present when the code is written, unless there is some even more outlandish way to use runt-time enum values.
I (and my previous manager) have been thru this, although it sounds like a good idea, it is not, unless its a static lookup table that will probably never change. Given that you are possibly stubborn and lazy, you could write a prebuild script to regenerate enums from the tables before you compile. Should not be hard (and should be a fun exercise).
xacc.ide - now with IronScheme support
IronScheme - 1.0 alpha 2 out now -
We all love to use enums instead of magic numbers, but what happens when the enums are based on a lookup table than can change? It seems like there's room here from some interesting dynamic code, possibly building the enum dynamically, but the conflict is with actual coding using the enum, as code can actually only use values present when the code is written, unless there is some even more outlandish way to use runt-time enum values.
Hmmmmm So you want some one to do this enum SomeEnum{ FirstElement=1, SecondElement=2 } Enum.ReAssign(typeof(SomeEnum),SomeEnum.FirstElement,3); :laugh: I don't think there is any microsoft guy around here who can introduce this in .Net 4.0 :doh:
Syed Muhammad Fahad Application Development Tyler Technologies -- TEMS Division mfahad@mazikusa.com