FWIW, I agree. I must have missed the earlier discussion as well. I
definitely prefer having an interface that can be used whenever a
specific implementation is not required.
Michiel Kalkman wrote:
I don't know the discussion, so the only thing I can say right now, is
that I don't like the names ... Or I just don't understand why it is
called XXXSource, which in my thoughts refers to the resource the
configuration is read from.
How about Configuration for the interface and something like
BaseConfiguration for the class ?
Regards,
Michiel
On 10/30/08, Oliver Heger <[EMAIL PROTECTED]> wrote:
A while ago we discussed whether in Configuration 2.0 the fundamental
Configuration object should be an interface or an (abstract) class, and
- as usual ;-) - we could not agree on a way to go.
Therefore I suggest the following compromise:
We keep an interface - let's call it ConfigurationSource - that is a
stripped down version of the Configuration interface we have now. This
interface contains only basic operations needed for accessing properties in
their "raw" form.
What is now AbstractConfiguration can become a concrete class
"Configuration". This class will be associated with a ConfigurationSource
object and implement more sophisticated operations on top of it. Here stuff
like data conversion, interpolation, or enhanced query facilities is
implemented.
An advantage of this approach is that we have a cleaner separation between
the basic management of configuration properties and high-level processing
of their values. We still have an interface, which has benefits, e.g. for
providing mock implementations or proxies, but extensions can be implemented
in a binary compatible way by modifying the new Configuration class (and
maybe defining sub interfaces of ConfigurationSource). Because the
ConfigurationSource interface has only a handful of methods, it is easier to
implement than the overloaded Configuration interface of today.
I checked in a first draft version of a ConfigurationSource interface [1].
Of course we can discuss the methods this interface should have. For
instance, methods like flush() and sync() dealing with persistence could be
added.
WDYT?
Oliver
[1]
http://svn.apache.org/viewvc/commons/proper/configuration/branches/configuration2_experimental/src/main/java/org/apache/commons/configuration2/base/ConfigurationSource.java?view=log
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
