You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Christof May <ma...@chrismay.de> on 2012/03/21 18:44:29 UTC
[configuration] Enum constants as keys
Hi all,
I'm not sure if this issue has been discussed before (couldn't find
anything on the mail list thou...), but what do you guys think of using
type-safe enum constants as keys instead of plain String values?
I assume there is a general understanding here that using enum constants
instead of strings is the "right thing" to do, but obviously there are
also important reasons not do so (legacy code, interface changes,
pre-Java1.5 stuff etc...). But I guess the most important one is that
Java enums never have been designed to work in a generic form (namely:
no abstract enums and/or enum inheritance). So there is no way to put an
enum placeholder in a library, and provide the concrete enum values in
the implementing application. An issue which I and other people already
have bemoaned (see
http://java.dzone.com/articles/java-should-have-extended for example),
but it is nevertheless a given fact we have to live with in the
foreseeable future... :(
Having said that, I just see two ways of using enum constants for
fetching config values. For one just using a lame
config.getWhatever(MyEnum.key.name()) everywhere. It would be a start,
but well.. not really what I was searching for...
The other solution I see would be to mark the enums with a marker
interface, and take that as the key placeholder, such as:
public interface Configurable {
public String name();
}
public interface Configuration {
boolean getBoolean(Configurable key);
(other methods follow here...)
}
In the application you would define the keys in an enum such as that:
public enum MyKeys implements Configurable {
FOO,
BAR,
...;
}
Then you could access the config values in real type-safe way:
boolean myValue = config.getBoolean(MyKeys.BAR);
Another advantage would be that enum constants can be easily enriched
with meta-data (via a custom annotation), for example:
public enum MyKeys implements Configurable {
@ConfigData(
defaultValue="foo",
type=String.class,
mandatory=true,
pattern="[a-z]{1,4}",
reload=false)
FOO,
...;
}
The possibilities here are endless (see also my pet project at
www.soplets.org exploring more in-depth the meta-data aspects of
annotations), but for a beginning having just enum constants alone would
be a good start in my view...
What do you think about that proposal, does that make any sense? Any
other options I have overlooked so far? Looking forward hearing your
opinions...
regards,
Chris May
Re: [configuration] Enum constants as keys
Posted by Emmanuel Bourg <eb...@apache.org>.
I agree with Oliver. I'm interested in exploring how annotations and
enums could be applied to configurations, but I think it's also
important to preserve the current flexibility of strings as keys.
The less intrusive change that comes to mind would be the use of an
Object as the key instead of a String. This would simplify the syntax
when enums are used as keys.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [configuration] Enum constants as keys
Posted by Oliver Heger <ol...@oliver-heger.de>.
Hi Chris,
this is certainly interesting stuff. Now that Commons Configuration
requires Java 1.5 at minimum, we are able to define an API which makes
use of enum constants.
Especially the aspect of annotation meta data seems promising IMHO.
There are surely many good use cases.
What I am not sure about is how to actually integrate this new feature
with the existing API. I think we should not enforce the use of enums in
general. Some applications may require generating keys dynamically;
also, HierarchicalConfiguration supports complex keys allowing the
selection of specific elements in hierarchical structures.
So should there be overloaded methods for both plain String keys and
enum keys? This would bloat the API. Would there be two different
Configuration interfaces?
Oliver
Am 21.03.2012 18:44, schrieb Christof May:
> Hi all,
>
> I'm not sure if this issue has been discussed before (couldn't find
> anything on the mail list thou...), but what do you guys think of using
> type-safe enum constants as keys instead of plain String values?
>
> I assume there is a general understanding here that using enum constants
> instead of strings is the "right thing" to do, but obviously there are
> also important reasons not do so (legacy code, interface changes,
> pre-Java1.5 stuff etc...). But I guess the most important one is that
> Java enums never have been designed to work in a generic form (namely:
> no abstract enums and/or enum inheritance). So there is no way to put an
> enum placeholder in a library, and provide the concrete enum values in
> the implementing application. An issue which I and other people already
> have bemoaned (see
> http://java.dzone.com/articles/java-should-have-extended for example),
> but it is nevertheless a given fact we have to live with in the
> foreseeable future... :(
>
> Having said that, I just see two ways of using enum constants for
> fetching config values. For one just using a lame
> config.getWhatever(MyEnum.key.name()) everywhere. It would be a start,
> but well.. not really what I was searching for...
>
> The other solution I see would be to mark the enums with a marker
> interface, and take that as the key placeholder, such as:
>
> public interface Configurable {
> public String name();
> }
>
> public interface Configuration {
> boolean getBoolean(Configurable key);
> (other methods follow here...)
> }
>
> In the application you would define the keys in an enum such as that:
>
> public enum MyKeys implements Configurable {
> FOO,
> BAR,
> ...;
> }
>
> Then you could access the config values in real type-safe way:
>
> boolean myValue = config.getBoolean(MyKeys.BAR);
>
> Another advantage would be that enum constants can be easily enriched
> with meta-data (via a custom annotation), for example:
>
> public enum MyKeys implements Configurable {
> @ConfigData(
> defaultValue="foo",
> type=String.class,
> mandatory=true,
> pattern="[a-z]{1,4}",
> reload=false)
> FOO,
> ...;
> }
>
> The possibilities here are endless (see also my pet project at
> www.soplets.org exploring more in-depth the meta-data aspects of
> annotations), but for a beginning having just enum constants alone would
> be a good start in my view...
>
> What do you think about that proposal, does that make any sense? Any
> other options I have overlooked so far? Looking forward hearing your
> opinions...
>
> regards,
>
> Chris May
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [configuration] Enum constants as keys
Posted by Christof May <ma...@chrismay.de>.
Hi Oliver, Emmanuel,
thanks for your reply.
> What I am not sure about is how to actually integrate this new feature
> with the existing API. I think we should not enforce the use of enums in
> general. Some applications may require generating keys dynamically;
> also, HierarchicalConfiguration supports complex keys allowing the
> selection of specific elements in hierarchical structures.
>
> So should there be overloaded methods for both plain String keys and
> enum keys? This would bloat the API. Would there be two different
> Configuration interfaces?
I fully agree with you that we shouldn't enforce the use of enums to the user, I guess there are enough cases where this would counter-productive. We shouldn`t break the current contract either, for example by changing the signature (e.g. changing the key type from String to Enum or Object) - you never know who relies on these signatures (use by reflection comes to my mind, the serial version number changes if not specified explicitly etc).
Instead I too would favor a second interface , one for 'classic' use, and one for the new approach. The implementing config classes could easily implement both of them, yet hiding their 'double face' from the public.
> The less intrusive change that comes to mind would be the use of an
> Object as the key instead of a String. This would simplify the syntax
> when enums are used as keys.
Hmm, I'm not so sure of this. For one you would change the signature of the methods (see above), and for the other you would defy the actual purpose of the enums, namely the type safety...
Chris May
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org