avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Tagunov" <atagu...@list.ru>
Subject MutableConfiguration
Date Mon, 02 Feb 2004 16:24:14 GMT
Hi, all!
I'm still around, just got LAN at home, you know :-)

1. ===================================

Niclas Hedhman wrote:

NH> What
NH> "I am creating my own container and would benefit to use 
NH> a defined interface during the creation of the Configuration
NH> object to be passed to the component."

Well, I can imagine a use case for it, that is I can imagine
two different MutableCofiguration interface implementations:

* one a-la DefaultConfiguration, with HashMap-s backing it

* and another: imagine we're porting to Java2ME
  (I'm going to get a pocket PC :-)
  and are _extremely_ low on memory;
  then we could back it withsomething else, like 

  TinyMutableConfiguration
  {
     String[5] keys;
     String[5] values;
  }

It would be a "tragedy" if there was only one implementation
for MutableConfiguration, but luckily there is more then one.
We see that the level of abstraction is however crusially
different from Configuration, LogEnabled, etc. So it will
best fit out of framework in my opinion too.


NH> Why
NH> "By having a interface defined in the Framework, a container
NH> can choose to provide an extension mechanism for collaborative
NH> construction of the Configuration object, which would work
NH> identically on more than one container."

We see, it belongs to some container-kit kind of interfaces,
or container-util, I would say. Really something like SPI.

2. ==================================

NH> HOW has been addresses a lot.
NH> 
NH> Consequences
NH> By placing the interface in the SPI package, it will not
NH> be part of the LifeCycle contract and more advanced containers
NH> can choose to prevent the components from the ability to down
NH> cast to it.

A most interesting point, see bellow..

NH> NOW,
NH> I would like to see that the interface MutableConfiguration
NH> DOES NOT extend Configuration, but has the same method
NH> signatures so that the implementation class can implement
NH> them both. That provides a better flexibility for the
NH> container on how to go about the creation process.

In fact this is the most interesting part for me:

indeed, it's a funny idea to prevent the component from
casting Configuration to mutable configuration. It's part
of Container-Component contract not to do this. To make
this even more evident I would suggest even the following:

public interface MutableConfiguration
{
    void setBlah( String key, ... );
    ...  set ...

    Configuration getConfiguration();
}

Only setter methods, and no getter methods.
Does not extend Configuration, instead contains the
getConfiguration() method which gives Configuration
providing read-only access to the same data.

This allowes us to avoid introducing the

    makeReadonly() method

that I've been proposing once

In fact we also avoid all this

void setBlah() throws InvalidStateException
{
    checkWritable();
    ...
}

logic that we might have to write otherwise.

An alternative for naming this interface might be
smth like ConfigurationMutator or .. dunno!

3. =============================

On the packaging choice.

I would say, go for some other package, not framework.
What about DefaultConfiguration? Just duplicate it.
Go for a similar class in -spi, or excalibur-configuration
package. Let DefaultConfiguration remain a legacy item
and let's in our future code pass MutableCofigurations
around. Will look nicer then passing DefaultConfiguration
as it happens a lot for instance in Fortress internals.

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


Mime
View raw message