Java enum functionality

The one thing that really bothers me is that you cannot do logical operations on enums.

IE:


enum Test
{
   OPTION1,
   OPTION2;
}

[...]
option = OPTION1 | OPTION2;
[...]

The only way I can think of doing this is to create a method and give each option an integer internally so you can compare the options and then return the final enum constant based on the integer logic operations.

If they can represent enums as bit vectors within internal memory then I’m sure they would have no problems allowing internal logical operations on enums.

Anyone else think this should have been done?

oh, I would have thought they would support that feature - after all, thats doable by the existing integer based “enums” >:(

This is what EnumSet is supposed to do.

  • elias

OMG!
A shity wrapper around a crap implementation!

public static <E extends Enum<E>> EnumSet<E> of(E e)
public static <E extends Enum<E>> EnumSet<E> of(E e1, E e2)
public static <E extends Enum<E>> EnumSet<E> of(E e1, E e2,  E e3)
public static <E extends Enum<E>> EnumSet<E> of(E e1, E e2,  E e3,  E e4)
public static <E extends Enum<E>> EnumSet<E> of(E e1,  E e2,  E e3,  E e4,  E e5)
public static <E extends Enum<E>> EnumSet<E> of(E first, E... rest)

ORing enums is actually a bit of an abuse :wink: Very poor programming. Seeing as enums can unexpectedly have a slightly different binary value if someone inserts a new one etc.

Cas :slight_smile:

Not the most useful part of the Java language. I basically use them for error checking my int flags.

Enums are NOT integers. That is one of the things that is corrected over the C++ concept of enums when the Java version was created.

ORing together two enums simply does not make sense. If you are thinking of Enums as simple constants then you’ve got it wrong.

Cohen-Sutherland line clipping anyone? </devils_advocate>

A specific algorithm isn’t relevant to the general concept of an enumeration.

But it makes sense in places that can have multiple states simultainiously. Java allows this internally! For example:


addKeyListener(new KeyListener(){
     public void keyPressed(KeyEvent ke)
     {
          switch(ke.getKeyCode())
          {
               case KeyEvent.VK_UP:
                    if(ke.getModifiersEx() == (KeyEvent.SHIFT_DOWN_MASK | KeyEvent.CTRL_DOWN_MASK))
                    {
                         doSomething();
                    }
                    break;
          }
     }
});

I understand that these are not enums, but it’s the same idea!

It’s relavent to your assertion that OR’ing enums doesn’t make sense.

Said algorithm uses region codes, which are ideally represented with enums. The algo requires these region codes to be AND’ed together in the process. It’s a well-known and simple example where logic operations on enums makes sense.

It’s the idea of storing the result of the OR back into an Enum is where it breaks down. I get what you mean about something being the combination of other things… but the combination can no longer be created as an enum that belongs to the same set as the others, unless of course you include the combination in the original definition of the enumerated type…

e.g. (psuedocode) enum LampState { RED, GREEN, YELLOW } where RED | GREEN = YELLOW… the result of the operation is still an enum because it is explicitly defined… you can probably get close to this with Java… though it won’t be as pretty as just using integer constants.

Is there a better way to do this and keep the type safety?

Yes, a Set.

ORing enums makes no sense whatsoever. The type you want to manage ORing bits is… ints!

Cas :slight_smile:

I don’t see what your object to EnumSet is. It seems a reasonable approach, which provides the type safety that has always been lacking when using bit operations directly. While there is some performance cost, speed isn’t that bad either.

My objection is that method signatures, and the fact that they’re not OR’able and Type safe. Since they broke the language with a new keyword (enum) they might have implemented it properly.

* Matzon grumbles something about generics being a bad hack too

Using naked bit operations to represent set operations is a bad hack too, albeit one of long standing.

I concede that the recursive generic declaration takes some understanding, but most people will just gloss over it and accept that it does the right thing. however without generics we have a semi-staticly type checked language which seems intellectually unsatisfactory. A sort of half way house between the fully dynamic languages and a complete static type checking. While some type casts are always likely to be necessary, without generics I find I have just too many of them for my peace of mind.