Re: use case for extending enum, but this is not possible in java
On 15.06.14 01.24, Laura Schmidt wrote:
In an application, there is an enum ListCommand that enumerates the
commands a user may execute on list entries:
public enum ListCommand
{
OPEN,
EDIT,
DELETE;
}
There is an interface that uses this enum:
public interface ListCommandProcessor
{
void onListCommand (ListCommand cmd);
}
[...]
public enum AppListCommand extends ListCommand
{
OPEN,
CLOSE,
SOMETHINGSPECIAL;
}
I wished something like that in other languages too. However, things are
not that easy as they appear. We had a similar discussion in the C++
group some time ago.
Extending a class means that you provide all the functionality of the
base class and anyone that can accept the base can deal with your
extension as well. But this does not hold true in your case.
What should a method accepting the base enum do when it receives an
unexpected value outside the range of the declared enum type? Note that
this is the other way around than for overridden methods. With methods
you call the overridden method with the parameters of definition in the
base class. What you expect is, that a method, that takes the base enum
parameters is called with parameters of your derived enum. It is like
covariance versus contravariance. You may always pass a refined type as
argument, but you can only receive a more general type than declared
from the return value. The /value/ of your enum is more like the return
value. So an instance taking the larger number of constants may also
store the values of the base enum, i.e. a method that can deal with the
extended enum may safely be called with the base enum type, but not the
other way around.
This would be my solution, but it is not possible in java to extend
enums.
Your requirements requires runtime polymorphism. Enums are not
polymorphic. In no language that I know of.
But I need to make a cut somewhere in order to move Listing<T>
into the generic library. The only solution I can imagine is to change
onListCommand (ListCommand cmd);
into
onListCommand (int cmd);
But then I would loose the beautiful type binding and I will soon find
myself defining list commands like it was done in the 90's in C:
public static final int CMD_OPEN = 1;
public static final int CMD_EDIT = 2;
public static final int CMD_DELETE = 3;
public static final int CMD_SOMETHINGSPECIAL = 55;
You can always use strong typing by wrapping the ints with a class.
You may also drop the int entirely and use instance equality instead.
This is approximately the way enums work in Java. They are basically
syntactic sugar.
class ListCommand
{
protected ListCommand();
public static final ListCommand CMD_OPEN = new ListCommand();
...
public ListCommand[] values()
{ return ...
}
}
If you are smart enough to replace the ListCommand constructor calls by
a private factory, then you might build the values array without
repeating yourself in the values method.
Note that you need to override values() in each derived class. It must
extend super.values() by it's own additions.
Of course, the java language could have implemented the enums this way
unless you declare them final. But because of the pitfalls above and
maybe because in 99% of the use cases enums are not polymorphic, they
have chosen to make them final by default.
Marcel