Leo:
Niclas does not need to veto anything because I already have. Lets stick with the real subject and the real concerns.
Firstly:
MultibleConfiguration should not be exposed under the Avalon client API.
Secondly:
MultibleConfiguration as you have proposed it extends Configuration which raises concerns related to client components casting an instance of Configuration to MutableConfiguration. While less evil than casting an instance to DefaultConfiguration - it remains evil. There have been some good suggestions about alternative approaches which I've found interesting - and which also suggest that this subject is not a done deal just yet. There are also equally valid points concerning the implications of the interface as part of a SPI contract and what this implies in terms of support. A complicating factor here is the continued instance of linking these subjects with the framework itself (which I happen to think is just plain wrong - but I also know that I'm probably in the minority here).
Anyway - there is perfectly valid question arising from the discussion. Should a MultableConfiguration be a Configuration - as opposed to the notion to something like:
public interface Graph
{
// contains all of the stuff in Configuration
}public interface Configuration extends Graph{}
public interface GraphMutator implements Graph
{
// contains the setter operationsConfiguration getConfiguration(); }
What this gives you is the assurance that a Configuration is not castable to something that is modifiable.
Cheers, Stephen.
Leo Sutic wrote:
From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
On Wednesday 04 February 2004 19:33, Leo Sutic wrote:
From: Niclas Hedhman [mailto:[EMAIL PROTECTED] What you add today, I and others have to support tomorrow.
So how come you think you have to support my implementation of configurators, just because I'm adding a MutableConfiguration interface?
Read up on the Apache Community concept.
Niclas,
I'm sorry, I don't see the connection. It is true that if I
add one piece of code (MutableConfiguration), then you have to
support the code I added - just as I have to support code you add. It isn't true that if I *don't* add a piece of code (my implementation of configurators), then you have to support
the code I *didn't* add.
/LS
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
