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: [email protected] For additional commands, e-mail: [email protected]
