Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of michielgkalkman@gmail.com
 designates 209.85.200.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=bW2ZnlsWiY6sC9/nz4yJuCkVVdUpcx4vcKzi9XXnewXyR0ynl2Nu/opab66YDRQtFv
         UiZJ2t6G1B4ddF0TrfOu1H/Y2iJLluqKhX/7x1OHrYg/QwO/xs/L7+42Hn91VN7TLW0N
         14ZDIvty+rLirs+g9fws0EyduuZDeKqynMlzI=
Message-ID: <ffdd47e0810300543g6decb5a2r86f5aaee45a51bbf@mail.gmail.com>
Date: Thu, 30 Oct 2008 13:43:03 +0100
From: "Michiel Kalkman" <michielgkalkman@gmail.com>
To: "Commons Developers List" <dev@commons.apache.org>
Subject: Re: [configuration] Interface vs class
In-Reply-To: <49095D30.60005@oliver-heger.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <49095D30.60005@oliver-heger.de>

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 <oliver.heger@oliver-heger.de> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org