commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christof May <>
Subject Re: [configuration] Enum constants as keys
Date Tue, 27 Mar 2012 07:59:29 GMT
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:
For additional commands, e-mail:

View raw message