All, in the discussion-but-was-supposed-to-be-a-vote of the MutableConfiguration interface some questions were raised regarding its usefulness, correctness, etc. I'd like to clarify my arguments for that interface.
WHAT IS IT? ----------- Put simply, the MutableConfiguration interface is the interface abstraction of the DefaultConfiguration class. So far, we have had: Configuration - interface - read-only DefaultConfiguration - class - read-write So if one wanted to only expose the read-only parts of a DefaultConfiguration, one would specify that a Configuration was passed. However, there are times when one wants to pass around a writable configuration object. So far, the obvious choice has been to pass around a DefaultConfiguration instance. But I would prefer if an interface could be passed around, instead of locking myself to a specific class. This makes for lower coupling. WHAT IS IT NOT? --------------- The MutableConfiguration interface has nothing to do with lifecycle extensions, or component persistence. While one surely can design such systems with the interface, the existence of the interface does in no way lock us into having to use it when designing the persistence mechanism. I also do not propose that the component persistence mechanism that I use be made part of framework. I merely brought it up to illustrate how *I* intend to use the interface. Another use would be internally in a container: when the container wants to alter a configuration before giving it to a component and doesn't want to pass around a concrete class to the parts doing the alterations. The interface is not a part of the container-component contract, as it does not exist in any of the lifecycle interfaces. In the future, should we decide to create new framework-level interfaces, it may - but that's for the future, and then only if a case can be made for it. WHY PUT IT IN FRAMEWORK? ------------------------ Because DefaultConfiguration, which is the (I believe) by far most commonly used example of a mutable configuration object, is in framework. Putting the interface in Excalibur would mean that the class that is the prime example of an implementation of it would not implement the interface. This makes no sense. I have no problem putting it in avalon-framework-impl instead of -api, though. /LS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
