Another word about Enumerations

Another word about Enumerations

• Jimmy_fingers

  I hate casting to int also, so if the int value is realy important, than sing the const int would be the way to go.

  Although, you should reconsider if casting to int is really necessary. For an array index, an int is truly needed, but for an application state, it can probably live it whole life as an enum.

  
  
  

• Cemal

  Hello All.

  James:

  Duh!! I guess I haven't had enough coffee yet this morning. Yes, I would have to declare the method signature with int parameters, because that's what the members of the struct are. Okay, check my thinking on this.

  Enums seem to make more sense from the standpoint of library code. If I were writing code that someone else would call, then certainly I would want to restrict the parameters to a specific list, and require the cast to (int) if they wanted the integer value.

  But, since this is not going to be library code, and all I'm interested in is the integer value, and especially because I can't stand looking at type casts if I can help it, I think the structs are the way to go, because:

  1. I'm using them for application states and matrix lookups to make the code readable.
  2. I'm not using them as method parameters, but as I say, that's not really relevant to this code.
  3. I don't care about the string representation at all.
  4. I cannot abide type casts if there is any way around them.

  Now, given this set of circumstances, do you see any land mines with this approach

  
  
  

• seco

  Hello All.

  James:

  Thanks for your reply. Okay, maybe I'm missing something here. Aren't structs types as well Specifically, value types just like enums

  So, to swipe your example:

  internal struct Cooking
  {
  int const Bake = 0;
  int const Broil = 1;
  int const Fry = 2;
  }

  public bool CookDinner(Cooking how, Fruit what);

  I'm not understanding why I would have to write

  public bool CookDinner(int how, int what);

  because the members of struct Fruit are: Fruit.Apple, Fruit.Pear, Fruit.Orange, and the members of Cooking are: Cooking.Bake, Cooking.Broil, and Cooking.Fry.

  Aren't they

  
  
  

• soni_ace

  You completely overlook enums most important feature -- they are types.  Consider this:

  Let's say we have Fruit declared as you have, and also a Cooking enum/struct:
  enum Cooking {Bake, Broil, Fry};

  As classes,  we would write:

  public bool CookDinner(Cooking how, Fruit what);

  However, as structs, we'd have to write:

  public bool CookDinner(int how, int what);

  So, if we were to call it like this:

  CookDinner(Pear, Bake);     // Should be CookDinner(Bake, Pear);

  As enums, I'd get a compile-time error.  As structs, you'd get a Broiled Apple at runtime.

   

  
  
  

• LotusExigeS1

  Hello All.

  nobugs:

  Thanks for your reply. Yes, I've noticed that a common use of consts is individually declared at the class level. The implementation approach I'm thinking about is more analogous to an enum.

  Instead of :

  internal enum Fruit {Apple, Pear, Orange};

  I'm thinking:

  internal struct Fruit
  {
  int const Apple = 0;
  int const Pear = 1;
  int const Orange = 2;
  }

  That way, the scope is namespace level, and the usage is still "Fruit.fruitname", which will return an int.

  
  
  

• Dan Mikkelsen

  I'm not understanding why I would have to write public bool CookDinner(int how, int what);

  Yes, struct is a type, but you aren't passing a Cooking struct to the method, just one piece of it.

  The struct Cooking is all three ints together, while Cooking.Bake is just an Int, not a Cooking struct.

  On the other hand, Fruit.Apple is an instance of the Enum type. It happens to have the same size & shape as an Int, but the compiler considers them distinct types.

  
  
  

• jeje1g

  Hmm, my personal preference is to stick with enums for that kind of thing.
  
  

• DmytroL

  Hello All.

  James:

  Thanks for replying. Yes, that particular consideration is what started all of this brain fever in the first place. In this case, for any given application session state (or type, if you will), the particular state is one of the indexes into the matrix lookups, so, there again, the integer part is what is required. When I first started the rough layout on paper, I went naturally to enums. But, as I began to flesh out the design, all of those type casts starting really getting on my last nerve.

  However, thanks in no small part to yourself and these forums, I now have a better mental picture of enums as they contrast with structs, which is all good.

  Thanks for your participation.

  
  
  

• Deepu_a

  Enums are types, consts are not. If you're only interested in the use of their values and don't ever want to assign a variable or field that has the enum type, use consts. Note however that the scope of an enum is the namespace in which they are declared, the scope of a named constant is the class in which they are declared. That can make the name of the constant a bit awkward when used outside of the class. Maybe that's why the framework programmers prefer enums so much
  
  
  
• Another word about Enumerations