From: Stephen McConnell [mailto:[EMAIL PROTECTED]
Leo:
Niclas does not need to veto anything because I already have.
Stephen,
still, he's a committer and *can* veto. While he hasn't done so, he's not part of any existing consensus among some committers that MutableConfiguration should be added. I think any reasonable definition of consensus must mean that no committer opposes the proposal enough to vote "No". While that wasn't a -1 veto, it was strong enough and might become one.
Firstly:
MultibleConfiguration should not be exposed under the Avalon client API.
+1, but a clarification is required:
Given that in Fortress and Merlin, components can be containers, do you mean that MutableConfiguration should just not be part
of what we now call framework-api?
Absolutely correct.
Irrespective of the ability of a container to be a component - this changes nothing in terms of the role and function of the Configuration interface. While I may have a component that manipulates a configuration - I may also supply a configuration to that component for the purpose of configuring the manipulator - two different concerns - but two concerns that are blurred when MutableConfiguration extends Configuration.
Anyway - there is perfectly valid question arising from the discussion. Should a MultableConfiguration be a Configuration
I'd say: A MutableConfiguration isa Configuration, but there
should be some way of keeping the client from casting a Configuration to a MutableConfiguration.
So how can this be done?
1. Don't expose the MutableConfiguration interface in a ClassLoader common to the container and the client. This means that the DefaultConfiguration passed in by the container will implement MutableConfiguration, but the container and client will have different MutableConfiguration classes loaded in their classloaders, and the client cast will therefore fail.
2. Provide a ConfigurationProxy class that wraps a Configuration and only implements Configuration. The container should wrap any DefaultConfiguration passed to the client in this class.
Both of the above deal with the problem of prevention of misuse arising from casting. A third alternative is to establish an object model in which the problem does not exist in the first place. That was what I was suggesting in my prev. post. I.e. MutableGraph versus MultableConfiguration. Benefits are that no preventative action is required by a container combined with a clearer separation of responsibilities.
What do think?
Stephen.
/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]
