Stephen McConnell wrote:
I don't have anything against the Configuration interface per se. As a generic way of providing access to configuration data it is great. I do, however have two issues with it:
Hmmmm. I am not sure that I fully follow what you are saying here, but I believe I have the gist of it. When I initially looked into the Avalon configuration subsystem, I was disappointed to find that we are forced into a quite sizeable Configuration interface for configurating our Configurables. Further, this interface exposed XML-specific namespace stuff to the Configurable, when (IMHO) that ought to be an implementation detail used by the parser when reading the config.xml and creating the Configuration impl.
I'm not familiar with the XML-specific namespace stuff - but I do know the there is broad support for the Configuration interface. It is simply really really nice to work with. If the Mailet API comes up with something new - I really hope it looks and smells like the Avalon Configuration interface.
1) If the author of a particular Configurable wants to go to the effort of providing a custom Configuration object, he is likely to want to provide accessors like: getMyAttribute() rather than getAttribute("myAttribute"). It would be good if he could implement an interface higher up the inheritence tree that didn't force him to expose the getAttribute("myAttribute") interface when he wasn't going to use it. In cases where a given Configuration implementation was re-used by many Configurables, possibly written by different authors, providing getMyAttribute() rather than getAttribute("myAttribute") provides a compile time defence against typos spelling "myAtribute".
2) The namespace thing, as mentioned before, is a technical detail that only the parser should be concerned with. If a particular Configuration author want's to expose it for some special reason, fine, he can add the method to his implementation class. The trouble is that (IMHO) most Configuration authors are going to want to encapsulate the namespace as an implementation detail that the Configurable should have no knowledge of. In Avalon, it is impossible to encapsulate this because the interface forces you to expose it. (Throwing UnsupportedOperationException is always ugly.)
If the getNamespace() method were removed entirely, I would be quite happy.
If the various getX(String name) methods were moved to a subclass/subinterface, (maybe StandardConfiguration,) allowing me to slot in configurations that exposed their own accessors, I would be ecstatic.
Cheers
ADK
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
