Hi Roedy,

My ideas:

Use a simple class instead of an enum:

class Color {
  static final Color red=new Color(255,0,0);
}

class Color2 {
  static final Color pink=new Color(255,200,200);
}

BTW: I suppose you know the reason, *why* sun decided to make enums not
extendable!?

I think there is no necessity to do so. Of course, it might have been
"nicer" to write "String content=File.read(...);" instead of "String
content=MyUtilFileClass.read(...);", but I think it is not really that
important.

No possibility. You cannot even do that with classes, because you simply
cannot convert an Object of type "MySuperClass" to an Object of
"MySubClass". Of course, you may use static helper classes, but I think
you do not want to hear this! ;-)

Same as (3): Because Java has a very statical type system and an Object
(for clarification: in contrast to a reference) can never change its
type! Of course, you may use a (Weak)HashMap to "append" new attributes
to some Objects, but this is no clean solution, IMHO. Another
possibility is to "wrap" your Objects in new Objects which have the
required attributes.

Ciao,
Ingo

On Mon, 16 Jul 2007 11:54:41 GMT, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

Why would I want to do such a thing?  In this case I am working on the
Replicator which has two halves  the applet that runs at the client
and the sender than runs on my machine.  I wanted to keep the client
code as small as possible.

So wanted to have a core enum class, and extend it with extra methods
on each enum constant only used by the receiver and ditto for the
sender.

I did not want to repeat code since it would not stay in sync.  So
what I did was a bit ugly but it works.

I passed an enum constant of the common enum class to the
corresponding enum constructor on the extending class.  Then I wrote
wrapper methods to let the extending class present the common methods.