Nested enums

[unomystEz]

I have a protocol structure that makes use of subcommands and I was
wondering if it's possible to do something like the following:


public enum MajorCommand {

LOGON { public enum SubCommand { }; }

QUIT { public enum SubCommand { IMMEDIATELY, DELAY }; }

LIGHT { public enum SubCommand { TURN_ON, TURN OFF}; }


public abstract enum SubCommand;

}


It would help a lot with the organization of the various combinations
possible.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I have a protocol structure that makes use of subcommands and I was
wondering if it's possible to do something like the following:

public enum MajorCommand {

LOGON { public enum SubCommand { }; }

QUIT { public enum SubCommand { IMMEDIATELY, DELAY }; }

LIGHT { public enum SubCommand { TURN_ON, TURN OFF}; }

public abstract enum SubCommand;

}

No.

Depending on how you want to use it then other OOP
techniques may be possible.

Arne

 

[unomystEz]

No.

Depending on how you want to use it then other OOP
techniques may be possible.

Arne

Hi Arne,

The 2 purposes for using enums to build command-sets is: 1. it is
extremely fast O(1) to match commands or find out if a command doesn't
exist (mistyped) opposed to iterating using String.equals(). 2. It
provides a documented list of the available commands and coupled with
some IDEs, the developer knows what commands are available while
implementing.

Doing the top-level enum (for major commands) worked well. FYI or
command structure is something like COMMAND [SUBCMD] [PARAM1 PARAM2
.... PARAMn] with SUBCMD being optional. Since SUBCMDs vary for
each COMMAND, I was hoping I could build an enum specific for each
COMMAND enum-constant so even at design-time we have a good reference
of "what are the possible SUBCMDs for this given COMMAND?"

The way I'm doing it now is prepending SUBCMD with it's parent COMMAND
(like AUTH_DUPLICATE_LOGIN) and putting all SUBCMDs in 1 enum, and now
it has grown to over a 100 or so and it's not fun to work with.

Also, whatever solution may exist, I would prefer if it could be
built/generated at design-time rather than runtime so IDE can take
adavantage their inspection.

cheers

 

[ricky.clarkson]

I recognise that name..

Try not to design in terms of enums, but in terms of interfaces. If
the implementation ends up looking like an enum, then sure, for
clarity, make it an enum.

In this example, I would have something like:

interface MajorCommand
{
Iterable<SubCommand> possibleValues();
}

interface SubCommand
{
}

enum Commands
{
LOGON
{
public Iterable<SubCommand> possibleValues()
{
return Collections.emptySet();
}
},
QUIT
{
public Iterable<SubCommand> possibleValues()
{
SubCommand[]
subCommands=QuitSubCommands.values();
return Arrays.asList(subCommands);
}
},
LIGHT
{
public Iterable<SubCommand> possibleValues()
{
SubCommand[]
subCommands=LightSubCommands.values();
return Arrays.asList(subCommands);
}
}
}

enum QuitSubCommands
{
IMMEDIATELY,
DELAY
}

enum LightSubCommands
{
TURN_ON,
TURN_OFF
}

 

[unomystEz]

Hey ricky,

Sorry for the delay in the reply.. good to know you are here as
well.

After reading your reply it does make sense to me to start from an
interface perspective and see where it ends up rather than trying to
leverage enums (I've been on an enum kick lately =))

Dealing with protocol suites can be quite messy, especially when you
try to design it cleanly, use it safely and synchronize it against its'
documentation.

regards

I recognise that name..

Try not to design in terms of enums, but in terms of interfaces. If
the implementation ends up looking like an enum, then sure, for
clarity, make it an enum.

In this example, I would have something like:

interface MajorCommand
{
Iterable<SubCommand> possibleValues();
}

interface SubCommand
{
}

enum Commands
{
LOGON
{
public Iterable<SubCommand> possibleValues()
{
return Collections.emptySet();
}
},
QUIT
{
public Iterable<SubCommand> possibleValues()
{
SubCommand[]
subCommands=QuitSubCommands.values();
return Arrays.asList(subCommands);
}
},
LIGHT
{
public Iterable<SubCommand> possibleValues()
{
SubCommand[]
subCommands=LightSubCommands.values();
return Arrays.asList(subCommands);
}
}
}

enum QuitSubCommands
{
IMMEDIATELY,
DELAY
}

enum LightSubCommands
{
TURN_ON,
TURN_OFF
}

I have a protocol structure that makes use of subcommands and I was
wondering if it's possible to do something like the following:


public enum MajorCommand {

LOGON { public enum SubCommand { }; }

QUIT { public enum SubCommand { IMMEDIATELY, DELAY }; }

LIGHT { public enum SubCommand { TURN_ON, TURN OFF}; }


public abstract enum SubCommand;

}


It would help a lot with the organization of the various combinations
possible.

 

[ricky.clarkson]

Definitely.

I've written an IP stack or two in Java, and it didn't help that on the
second one I was just starting to learn Java 1.5's features - it took
quite some messing around before I got it right (assuming I actually
did get it right!).

The IP stack is in IPSim ( http://www.ipsim.com ), FYI.

Hey ricky,

Sorry for the delay in the reply.. good to know you are here as
well.

After reading your reply it does make sense to me to start from an
interface perspective and see where it ends up rather than trying to
leverage enums (I've been on an enum kick lately =))

Dealing with protocol suites can be quite messy, especially when you
try to design it cleanly, use it safely and synchronize it against its'
documentation.

regards

I recognise that name..

Try not to design in terms of enums, but in terms of interfaces. If
the implementation ends up looking like an enum, then sure, for
clarity, make it an enum.

In this example, I would have something like:

interface MajorCommand
{
Iterable<SubCommand> possibleValues();
}

interface SubCommand
{
}

enum Commands
{
LOGON
{
public Iterable<SubCommand> possibleValues()
{
return Collections.emptySet();
}
},
QUIT
{
public Iterable<SubCommand> possibleValues()
{
SubCommand[]
subCommands=QuitSubCommands.values();
return Arrays.asList(subCommands);
}
},
LIGHT
{
public Iterable<SubCommand> possibleValues()
{
SubCommand[]
subCommands=LightSubCommands.values();
return Arrays.asList(subCommands);
}
}
}

enum QuitSubCommands
{
IMMEDIATELY,
DELAY
}

enum LightSubCommands
{
TURN_ON,
TURN_OFF
}

I have a protocol structure that makes use of subcommands and I was
wondering if it's possible to do something like the following:


public enum MajorCommand {

LOGON { public enum SubCommand { }; }

QUIT { public enum SubCommand { IMMEDIATELY, DELAY }; }

LIGHT { public enum SubCommand { TURN_ON, TURN OFF}; }


public abstract enum SubCommand;

}


It would help a lot with the organization of the various combinations
possible.