No generic enums ...

  • Thread starter Lasse Reichstein Nielsen
  • Start date
L

Lasse Reichstein Nielsen

Hi all.

I was taking yet another look at generics, and noticed that enums cannot
be generic.

After all, the "enum" construct is syntactic sugar for the traditional
type safe enum pattern, and with generics, you could write something like:

---
class RandomConstant<T> {
public final RandomConstant<Integer> INT =
new RandomConstant<Integer>(new Integer(87));
public final RandomConstant<String> STRING =
new RandomConstant<String>("hello world");
private final Object v;
RandomConstant(T value) {
this.v = value;
}

public T value() {
return (T) v;
}
}
---
(yes, braind dead example :)

I was thinking that I should be able to write that with an enum,
something syntactically like this:
---
enum RandomConstant<T> {
INT<Integer>(new Integer(87)),
STRING<String>("hello world");

private final Object v;
private RandomConstant(T value) {
this.v = value;
}

public T value() {
return (T) value;
}
}
---

Alas, it isn't so. Does anybody know whether this is a deliberate choice,
and if so, what the reasoning behind it is (or am I just generalizing
too far as usual :)?

Regards
/L
 
C

Chris Uppal

Lasse said:
Alas, it isn't so. Does anybody know whether this is a deliberate choice,
and if so, what the reasoning behind it is (or am I just generalizing
too far as usual :)?

I suspect that you may be generalising too far in this case. I'm not one of
the Java designers, but it seems to me that the idea of eniums is that they are
/opaque/ names, rather than named constant values. As such I don't think that
being able to specifiy values of different types would be an design aim.

Of course, you can always continue to roll-your-own. There's no law saying you
have to use the new syntax.

-- chris
 
L

Lasse Reichstein Nielsen

Chris Uppal said:
I suspect that you may be generalising too far in this case. I'm
not one of the Java designers, but it seems to me that the idea of
eniums is that they are /opaque/ names, rather than named constant
values. As such I don't think that being able to specifiy values of
different types would be an design aim.

Hmm, if they were only opaque names, then something simpler could be
used.

I see enums as the solution when a class is known to have a fixed,
known number of instances. Hmm, Singleton would be a special case of that:
---
public enum MySingleton {
INSTANCE;
// yadda yadda
// perfect singleton, except you can't do lazy initialization
}
---

Aynway, that is what the Type Safe Enum pattern does. Check, e.g., the
Operation enum from Bloch's "Effective Java Language Programming Guide
for an enum that is not just opaque names:
<URL:http://java.sun.com/developer/Books/shiftintojava/page1.html#replaceenums>


.... but I must also admit that when I think of enum values in
genenral, I also have the feeling that they should be fairly
symmetric, so having different types is probably not needed.
Of course, you can always continue to roll-your-own. There's no law
saying you have to use the new syntax.

But I like it! :)

Thanks
/L
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,774
Messages
2,569,596
Members
45,143
Latest member
DewittMill
Top