> I think, intValue() would have to be generic...:
It depends. If it is, then you end up with Integer types for something
that cries for int primitive types (very common). In my case, I would
have to re-implement all my enums (200-300) which I would not do.
Let's be practical. In the world, there are only few real enumeration types:
- int values.
- String values.
- Eventually char values (e.g.: Y/N), which are like Strings of length one.
I don't deny that someone could make an EnumType<Date>, but I guess
you get my point :)
> public interface EnumType<T> {
> public T getLiteral(); // The existing literal corresponds to intValue()
> }
Having answered my feeling on such a signature for int values, I will
elaborate on the impact of user code. Considering that these are enums
used in actual user code, I can bet that we would soon see:
if(myEnum.getLiteral() != null) {
// Do something.
}
because the problem with type wrapper is that they convey the null
possibility. I am sure some integrists would even go as far as using:
myEnum.getLiteral().intValue()
> public V getEnum() would have to be made static and moved to some
> registry. It doesn't make sense in an interface, I think.
True of course, I was too quick crafting the code.
My DB enums all have a static getEnum(int) method which is within the
enum itself. It would be more desirable to make closer the enum and
its lookup code rather than having to build a central registry.
Maybe you could have a contractual API: if a getEnum method is
available through reflection (loaded only once per enum and cached so
not a performance issue), then this API is used. If not, it would
iterate on the values() until intValue() returns the expected one.
Performance improvements would just be a matter of implementing the
getEnum method. Alternatively (or in addition if the getEnum method is
not declared), jOOQ could iterate once per enum and establish that
mapping once and for all, though I don't know if that can have nasty
performance issues in practical case (I doubt it).
> - The "base type" for jOOQ's EnumType is lost, i.e. the synthetic
> EnumType has no reference to its original DataType or to the generic
> type <T>. This means, only VARCHAR enum types work right now (and some
> others in lenient, "forgiving" databases)
Hence the practical approach I described:
- VARCHAR enums -> String-based enums
- NUMBER enums -> int-based enums
- CHAR enums -> char-based enums.
-Christopher
