avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject MutableConfiguration
Date Fri, 23 Jan 2004 09:31:50 GMT
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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message