commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [lang] Enums
Date Sun, 21 Jul 2002 07:29:01 GMT

I agree that the Properties concepts Dimitri's library contains is
probably not something we want to leap into. He does have one important
thing that the Avalon libraries don't, that being the readResolve method
which is essential to allow code to say:

if(someVar == Colour.RED) {

and have it work in a distributed environment. I believe this will need to
be added to your list of things to add to the Avalon.Enum.

On Sat, 20 Jul 2002, Stephen Colebourne wrote:

> First discussion point for adding to lang - Enumeration superclass.

> Although Dimitris is more function rich, I think I prefer the Avalon code to
> start from. However, I would like to change the following in Enum:

> - Map handling code built in, rather than needing the subclass to be aware
> (note this may require a lightweight map implementation?)

+1 on moving it away from the subclass. Why would it require a lightweight
map implementation? Using a HashMap would hurt performance that much?
One idea, though maybe not great, we could use reflection to use a
FastHashMap from Commons.Collections [I think they have one] if it's in
the classpath.

> - asMap() method on Enum that returns the Map (unmodifiable)
> - asCollection() method on Enum that returns the values Collection
> (unmodifiable)
> - iterator() method on Enum that returns the value iterator of the Map
> (unmodifiable)
> - getEnum(String name) method that returns a typecast Enum object by name
> from the Map


> - the equals() method could use == for comparing Class objects?

Yeah, is there a time when two objects can belong to the same Class, but
calling getClass() returns different objects? I guess if different
ClassLoaders were used?

> - javadoc recommendation for the subclass to have a typecast get by name
> method

As in:

public Colour getColour("RED") {
    return (Colour)super.getEnum("RED");


If so, +1. We could make this a runtime check? The Enum constructor could
do reflection upon itself to ensure the convention is held to? A bit heavy
handed though.

> to ValuedEnum I would change:
> - remove isXxx() methods, these are rather non-standard and encourage int
> comparisons (which the class is aiming to avoid!)

-1. Kinda. I thought that having an ordering to the underlying elements in
an Enum was important [Not often C coder, just never seem to find the

In fact, I'm not convinced by the whole ValuedEnum construct. I would have
thought an OrderedEnum construct would have been better, the enums would
be organised some how in order, but it would not be possible for two enums
to be equal [unless their equals() said they were] which removes your
point below.

I guess the important part is: Is the class mostly useful for the ordering
of the enums or the fact that each enum has a value which can be obtained?

It seems to me that the value part of it is something any sub-class can
very easily add. Using the value to infer the order would also be doable.

I think what I'm suggesting is:

OrderedEnum class.

Has an abstract compareOrder method which must be implemented.
This method is called by the isGreaterThan's etc, and also by the
Comparable.compareTo method, which is incidentally made final.
compareOrder would take two OrderedEnum's, but otherwise have the same
semantics as compareTo. The OrderedEnum class would ensure that the two
OrderedEnum's being passed in were of the same type, before calling

My lack of experience with C-enum's may mean I'm misunderstanding
something. I'll attempt to find time to put together the OrderedEnum code
as an example.

> - make the class Comparable based on the integer value (note that this means
> that Comparable equals will differ from equals()

See above. Else, I think it's okay as long as we javadoc it nice and loud.

> Let the discussion commence...

Sorry, finished.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message