Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #28734 > unrolled thread

use case for extending enum, but this is not possible in java

Back to article view | Back to comp.lang.java.programmer

Contents

  use case for extending enum, but this is not possible in java Laura Schmidt <ls@mailinator.com> - 2014-06-15 01:24 +0200
    Re: use case for extending enum, but this is not possible in java Steven Simpson <ss@domain.invalid> - 2014-06-15 01:04 +0100
    Re: use case for extending enum, but this is not possible in java Marcel Müller <news.5.maazl@spamgourmet.org> - 2014-06-15 02:53 +0200
    Re: use case for extending enum, but this is not possible in java markspace <markspace@nospam.nospam> - 2014-06-14 18:58 -0700
    Re: use case for extending enum, but this is not possible in java Robert Klemme <shortcutter@googlemail.com> - 2014-06-15 12:20 +0200
    Re: use case for extending enum, but this is not possible in java Robert Klemme <shortcutter@googlemail.com> - 2014-06-15 12:21 +0200
    Re: use case for extending enum, but this is not possible in java "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-06-15 11:58 +0100
    Re: use case for extending enum, but this is not possible in java Wanja Gayk <brixomatic@yahoo.com> - 2014-06-16 01:08 +0200
    Re: use case for extending enum, but this is not possible in java Roedy Green <see_website@mindprod.com.invalid> - 2014-06-15 22:20 -0700

#28734 — use case for extending enum, but this is not possible in java

Hi,

I have found a need to extend enum, but this is not possible in java. 
Take a look at the situation:

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

And there is a generic Listing class that is used to show customized 
lists in the GUI and which uses the above interface:

public class Listing<T>
{
  ...
  ListCommandProcessor processor;
  ...
}

So far, so good.

Now I am making a cut: The generic class Listing<T> should be moved into 
a generic java library, so that it can be used by different 
applications. So I also need to move the interface ListCommandProcesor 
into this library, and this would implicate that I also move the enum 
ListCommand into the library. But the enum ListCommand ist application 
specific. If I move it to the library, it must be extendable somehow. If 
there were no limitations in the java language, I would separate the 
concerns of library and application like this:

--- library:

public enum ListCommand
{
  // empty at library level
}

public interface ListCommandProcessor
{
  void onListCommand (ListCommand cmd);
}

--- application:

public enum AppListCommand extends ListCommand
{
  OPEN,
  CLOSE,
  SOMETHINGSPECIAL;
}

public class MyApp extends ListCommandProcessor
{
  ...
  Listing<XYZ> listing = new Listing<XYZ> ();
  listing.setProcessor (this);

  public void onListCommand (ListCommand cmd)
  {
   AppListCommand c = (AppListCommand) cmd;

   switch (c)
   {
    ...
   }
  }
}

This would be my solution, but it is not possible in java to extend 
enums. 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;

I know that this would be a way out, but I want to make sure that there 
is no better solution.

How would you do this?

Thank you,
Laura

[toc] | [next] | [standalone]

#28736

On 15/06/14 00: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);
> }
>
> And there is a generic Listing class that is used to show customized 
> lists in the GUI and which uses the above interface:
>
> public class Listing<T>
> {
>  ...
>  ListCommandProcessor processor;
>  ...
> }
>
> So far, so good.
>
> Now I am making a cut: The generic class Listing<T> should be moved 
> into a generic java library, so that it can be used by different 
> applications. So I also need to move the interface ListCommandProcesor 
> into this library, and this would implicate that I also move the enum 
> ListCommand into the library. But the enum ListCommand ist application 
> specific. If I move it to the library, it must be extendable somehow.

Does your Listing class demand anything of ListCommand?  Does it even 
require it to be an enum?  If not, does this help?:

   // In library
   public interface Processor<E> {
     void onListCommand(E cmd); // inappropriate name now?
   }

   public class Listing<T, E> {
     Processor<E> processor;
     public void setProcessor(Processor<E> processor) {
       this.processor = processor;
     }
   }

   // In application
   public enum AppListCommand {
     OPEN, CLOSE, STUFF;
   }

   public class MyApp extends Processor<AppListCommand> {
     {
       Listing<XYZ, AppListCommand> listing = ...;
       listing.setProcessor(this);
     }

     public void onListCommand(AppListCommand cmd) {
       switch (cmd) { ... }
     }
   }

Depending on unspecified factors, you might be able to use Processor<? 
super E>, or have to use Listing<T, E extends Enum<E>>.

-- 
ss at comp dot lancs dot ac dot uk

[toc] | [prev] | [next] | [standalone]

#28739

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

[toc] | [prev] | [next] | [standalone]

#28741

On 6/14/2014 4:24 PM, Laura Schmidt wrote:

>   public void onListCommand (ListCommand cmd)
>   {
>    AppListCommand c = (AppListCommand) cmd;
>
>    switch (c)
>    {
>     ...
>    }


I have to agree with Marcel Muller here.  Enums, the way you use them, 
are not polymorphic.  And using a switch to emulate polymorphism is 
almost always a bad idea.  See Replace Conditional with Polymorphism.

http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html

However you can fake it a bit in Java.  Java enum are sorta-kinda 
polymorphic.  (I think that's the technical term.)


interface MyCommand {
   Object eval();
}

void onListCommand( MyCommand cmd ) {
   System.out.println( cmd.eval() );
}

public enum ListCommand implements MyCommand
{
  OPEN,
  EDIT,
  DELETE;
  public Object eval() { return this.ordinal(); }
}

public enum AppListCommand implements MyCommand
{
  OPEN,
  CLOSE,
  SOMETHINGSPECIAL() {
    public Object eval() { return "Hi";}};
  public Object eval() { return this.ordinal(); }
}

Not compiled or tested, although part was:

    public static void main( String[] args )
    {
       onListCommand( AppListCommand.OPEN, AppListCommand.CLOSE,
               AppListCommand.SOMETHINGSPECIAL );
    }
    private static void onListCommand( MyCommand... cmd )
    {
       for( MyCommand x : cmd ) {
          System.out.println( x.eval() );
       }
    }
run:
0
1
Hi
BUILD SUCCESSFUL (total time: 1 second)

[toc] | [prev] | [next] | [standalone]

#28744

On 15.06.2014 01:24, Laura Schmidt wrote:
> Hi,
>
> I have found a need to extend enum, but this is not possible in java.
> Take a look at the situation:
>
> 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);
> }
>
> And there is a generic Listing class that is used to show customized
> lists in the GUI and which uses the above interface:
>
> public class Listing<T>
> {
>   ...
>   ListCommandProcessor processor;
>   ...
> }
>
> So far, so good.
>
> Now I am making a cut: The generic class Listing<T> should be moved into
> a generic java library, so that it can be used by different
> applications. So I also need to move the interface ListCommandProcesor
> into this library, and this would implicate that I also move the enum
> ListCommand into the library. But the enum ListCommand ist application
> specific. If I move it to the library, it must be extendable somehow. If
> there were no limitations in the java language, I would separate the
> concerns of library and application like this:
>
> --- library:
>
> public enum ListCommand
> {
>   // empty at library level
> }
>
> public interface ListCommandProcessor
> {
>   void onListCommand (ListCommand cmd);
> }
>
> --- application:
>
> public enum AppListCommand extends ListCommand
> {
>   OPEN,
>   CLOSE,
>   SOMETHINGSPECIAL;
> }
>
> public class MyApp extends ListCommandProcessor
> {
>   ...
>   Listing<XYZ> listing = new Listing<XYZ> ();
>   listing.setProcessor (this);
>
>   public void onListCommand (ListCommand cmd)
>   {
>    AppListCommand c = (AppListCommand) cmd;
>
>    switch (c)
>    {
>     ...
>    }
>   }
> }
>
> This would be my solution, but it is not possible in java to extend
> enums. 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;
>
> I know that this would be a way out, but I want to make sure that there
> is no better solution.
>
> How would you do this?

To me this is pretty clear: ListCommandProcessor is an interface and 
needs an application specific implementation anyway to interpret the 
argument to onListCommand().  As you do not seem to define specific 
methods in ListCommand any implementation of onListCommand() is 
basically totally free to do what it needs to do with the argument and 
you do not have to constrain the argument type in any way.  So you make 
it generic.  So we have

Library part:


public class Listing<T,C> {
  ...
  private ListCommandProcessor<C> processor;
  ...
}

public interface ListCommandProcessor<C> {
  void onListCommand(C cmd);
}


Specific implementation:

public class MyList {
}

public enum ListCommand {
  OPEN,EDIT,DELETE
}

public class MyApp implements ListCommandProcessor<ListCommand> {
  ...
  Listing<MyList,ListCommand> listing =
    new Listing<MyList,ListCommand> ();
  listing.setProcessor(this);

  public void onListCommand(ListCommand cmd)
  {
   switch (cmd) {
    ...
   }
  }
}


An alternative approach might be to remove ListCommandProcessor 
altogether and use a more OO approach by implementing functionality 
inside the ListCommand (what is an enum now but could be something else).

Library part:

public interface ListCommand<T> {
  void execute(T list);
}

public class Listing<T> {
   ...
   public void someMethod() {
     final T list = ...
     final ListCommand<T> cmd = ...
     cmd.execute(list);
   }
   ...
}



Specific implementation:

public class MyList {
}

// this could be anything, not just an enum
public enum MyListCommand implements ListCommandProcessor<MyList> {
   OPEN {
     @Override
     public void onListCommand(MyList cmd) {
       // whatever
     }
   },
   EDIT {
     @Override
     public void onListCommand(MyList cmd) {
       // whatever
     }
   }
   ...
}

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#28745

On 15.06.2014 01:24, Laura Schmidt wrote:

 > I have found a need to extend enum, but this is not possible in java.
 > Take a look at the situation:
 >
 > 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);
 > }
 >
 > And there is a generic Listing class that is used to show customized
 > lists in the GUI and which uses the above interface:
 >
 > public class Listing<T>
 > {
 >   ...
 >   ListCommandProcessor processor;
 >   ...
 > }
 >
 > So far, so good.
 >
 > Now I am making a cut: The generic class Listing<T> should be moved into
 > a generic java library, so that it can be used by different
 > applications. So I also need to move the interface ListCommandProcesor
 > into this library, and this would implicate that I also move the enum
 > ListCommand into the library. But the enum ListCommand ist application
 > specific. If I move it to the library, it must be extendable somehow. If
 > there were no limitations in the java language, I would separate the
 > concerns of library and application like this:

 > How would you do this?

To me this is pretty clear: ListCommandProcessor is an interface and 
needs an application specific implementation anyway to interpret the 
argument to onListCommand().  As you do not seem to define specific 
methods in ListCommand any implementation of onListCommand() is 
basically totally free to do what it needs to do with the argument and 
you do not have to constrain the argument type in any way.  So you make 
it generic.  So we have

Library part:


public class Listing<T,C> {
  ...
  private ListCommandProcessor<C> processor;
  ...
}

public interface ListCommandProcessor<C> {
  void onListCommand(C cmd);
}


Specific implementation:

public class MyList {
}

public enum ListCommand {
  OPEN,EDIT,DELETE
}

public class MyApp implements ListCommandProcessor<ListCommand> {
  ...
  Listing<MyList,ListCommand> listing =
    new Listing<MyList,ListCommand> ();
  listing.setProcessor(this);

  public void onListCommand(ListCommand cmd)
  {
   switch (cmd) {
    ...
   }
  }
}


An alternative approach might be to remove ListCommandProcessor 
altogether and use a more OO approach by implementing functionality 
inside the ListCommand (what is an enum now but could be something else).

Library part:

public interface ListCommand<T> {
  void execute(T list);
}

public class Listing<T> {
   ...
   public void someMethod() {
     final T list = ...
     final ListCommand<T> cmd = ...
     cmd.execute(list);
   }
   ...
}



Specific implementation:

public class MyList {
}

// this could be anything, not just an enum
public enum MyListCommand implements ListCommandProcessor<MyList> {
   OPEN {
     @Override
     public void onListCommand(MyList cmd) {
       // whatever
     }
   },
   EDIT {
     @Override
     public void onListCommand(MyList cmd) {
       // whatever
     }
   }
   ...
}

Kind regards

     robert

[toc] | [prev] | [next] | [standalone]

#28747

Laura Schmidt wrote:

> Now I am making a cut: The generic class Listing<T> should be moved into
> a generic java library, so that it can be used by different
> applications. So I also need to move the interface ListCommandProcesor
> into this library, and this would implicate that I also move the enum
> ListCommand into the library. But the enum ListCommand ist application
> specific.

Think objects not integers (Java's enums aren't "integers in drag" anyway).

You have these command "things".  What does the general library need to know 
about them ?  Anything ?  If not then declare them as java.lang.Object. 
Otherwise either use an interface or generics (or both) to express the 
constraints on them.

    -- chris 

[toc] | [prev] | [next] | [standalone]

#28756

In article <lniljr$8h9$1@news.m-online.net>, Laura Schmidt 
(ls@mailinator.com) says...
> 
> Hi,
> 
> I have found a need to extend enum, but this is not possible in java. 
> Take a look at the situation:
> 
> 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);
> }
> 
> And there is a generic Listing class that is used to show customized 
> lists in the GUI and which uses the above interface:
> 
> public class Listing<T>
> {
>   ...
>   ListCommandProcessor processor;
>   ...
> }

[SNIP]

So basically what you're trying here is using an Enum as an event and of 
course that must fail in another application that needs more events than 
these. An Enumeration is just that: An enumeration, a fixed set of 
things. Since you want something extensible an Enumeration is not the 
weapon of choice.

> How would you do this?

According to your sample, you've picked one name to do something but 
you're doing something else.
Your naming suggest you want to process commands, but your 
implementation suggests you're processing events.
So why not stick with your naming and try to process commands instead?
That would inevitably point you to the Command Pattern for a start. 
that could look like a biut like this:

//you want something extensible, so use a class, an abstract class or an 
//interface:

package commands;
public interface ListCommand{ 
 void execute();
}

//now extend it:

//let's also hide the implementations using package visibility, 
//more on that later

package commands;
class Remove implements ListCommand{
  private final int index;
  Remove(Listing listing, int index){
   this.listing=listing; //or an ID,whatever is appropriate
   this.index=index;
  }

 public void execute(){
  //maybe do something specific here, like logging
  listing.remove(index);
 }

}

//let's create an interface for command processing:

public interface ListCommandProcessor {
 public void process(ListCommand command);
}

//and have a basic implementation for the basic case. That doesn't look 
//like rocket science (and pretty unnecessary), but read on:

package commands;
public class BasicListCommandProcessor implements ListCommandProcessor {
 public void process(ListCommand command){
   command.execute();
 }
}

// Now expose your commands via a Facade class, so you users don't need 
// to remember the implementations, so they have a single go-to-class. 
// And they don't see all the dirty implementation details:

package commands;
public class BasicListCommands{
 
 public ListCommand remove(Listing listing, int index){
  return new Remove(Listing, index);
 }

 public ListCommand edit(Listing listing, int index){
  return new Edit(Listing, index);
 }

 ///...

}

That's your framework, basically. Note that I'm not using static methods 
or singletons or a final class, we want to be open for extension here.
Which we will do now.

You could now extend your suite of commands by creating own command 
implementations and extending the suite:

//only visible in project A, that uses the framework above.

public class MyProjectListCommands extends BasicListCommands{

 public ListCommand magicOperation(final List list){
  return new MagicOperation(list);
 }
}

You could override the default behavior and add someting:

//only visible in project B, that uses the same framework above:

public class MyOtherProjectListCommands extends BasicListCommands{

 @Override
 public ListCommand edit(Listing listing, int index){
  return new SpecialEdit(Listing, index);
 }

 public ListCommand fascinatingOperation(final List list){
  return new FascinatingOperation(list);
 }
}


So for any bogus usage example, let's process some commands:
Imagine we want to do some special processing, logged and/or parallel:

//create some decorator to log every command
public class LoggingListCommandProcessor implements ListCommandProcesso{
 private static final Logger LOGGER 
   = Logger.getLogger(LoggingListCommandProcessor.class);

 private final ListProcessor delegate;

 public LoggingListprocessor(ListProcessor delegate){
  this.delegate = delegate;
 }

 public void process(ListCommand command){
  LOGGER.trace(command);
  delegate.process(command);
 }

}

//Imagine another decorator for doing parallel processing here

Now let's see how this could be used in some project with an extended 
command suite:

class Client{
 private static final MyProjectListCommands COMMANDS 
   = new MyProjectListCommands();

 private final ListCommandProcessor processor 
  = new LoggingListCommandProcessor(
     new ParallelListCommandProcessor(
      new BasicListCommandProcessor()
     )
    );

 void doEdit(){ 
  processor.process(COMMANDS.edit(someList, someIndex));
 }

}


So you see: you've got a whole lot of possibilities if you use good old 
classes and interfaces instead of enums here.

Kind regards,
-Wanja-


-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#28757

On Sun, 15 Jun 2014 01:24:47 +0200, Laura Schmidt <ls@mailinator.com>
wrote, quoted or indirectly quoted someone who said :

>How would you do this?

The only tool I have found that might be remotely  useful in this
situation is having your enums implement an interface.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Software gets slower faster than hardware gets faster. 
~ Niklaus Wirth (born: 1934-02-15 age: 80) Wirth's Law

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web