Extending an enum

[Roedy Green]

You can't extend an enum to either add more enum constants or more
static methods or more instance methods on the enum constants, or more
instance datafields on each enum constant.

Any thoughts on how to fake various types of extensions?
..

 

[Ingo R. Homann]

Hi Roedy,

You can't extend an enum to either
> Any thoughts on how to fake various types of extensions?

My ideas:

> (1) add more enum constants or

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!?

> (2) more static methods or

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.

> (3) more instance methods on the enum constants

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! ;-)

> (4) more instance datafields on each enum constant.

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

 

[Roedy Green]

You can't extend an enum to either add more enum constants or more
static methods or more instance methods on the enum constants, or more
instance datafields on each enum constant.

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.

 

[Daniel Pitts]

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.

Perhaps "enum" isn't the right construct for you. Perhaps an
extensible type token is what you're looking for?

 

[Roedy Green]

Perhaps "enum" isn't the right construct for you. Perhaps an
extensible type token is what you're looking for?

I think you are right. I started with an enum solution based on ints.
By the time I was done I had no more switches, so that got rid of the
#1 attraction of enum.