Hi Leo:
This is shaping up into something nicely.
More notes in-line.
Leo Sutic wrote:
a) Where does it belong?
Can we solve this by a simple majority vote?
Sure.
1. avalon-framework-api 2. avalon-framework-spi 3. avalon-framework-impl
Just a small note - the avalon-framework-api option is not an option due to the standing veto and should not be included in the vote - aside from that it looks good.
Everyone casts a vote for any repo where they want it. (Mutliple choices allowed.) Then we take the one with the most votes and just go with it.
Yep.
Not optimal for anyone, but I've read arguments for all three, and they have about equal weight in my mind.
b) Should MutableConfiguration extend Configuration?
Problem here being that a component may
downcast from Configuration to MutableConfiguration.
An upcast from MutableConfiguration to Configuration
should be no problem - but...
I read the javadocs for Configuration and it states that a Configuration is immutable. The question now is: for how long? Is the Configuration passed to the component immutable for the duration of the configure() call or for all time? If the component keeps a reference to the Configuration passed in, is the Configuration guaranteed not to change for as long as the component holds the reference?
My assumption is that the configuration is immutable from the time that the configuration is exposed to the client via configure, up to the point where either:
(a) the component is suspended (b) the component is disposed
We have to assume that component writers think so.
Therefore, a MutableConfiguration isa Configuration in terms of methods implemented, but not in terms of immutability. However, for functions that only rely on the Configuration being immutable for the duration of the call, it can be. For example:
public class MyUtils { public static void serialize (Configuration config) { ... } }
In this case, the serialize method expects the configuration not to change while it is executing - but what you do with the configuration after you have called it, it doesn't care about.
I propose the following: I'll code a class that is called DefaultImmutableConfiguration. It will only expose the Configuration interface, and it will look like this:
public class DefaultImmutableConfiguration implements Configuration {
DefaultImmutableConfiguration (Configuration config) { ... }
}
The constructor will do a deep copy of the supplied Configuration, thus ensuring that the instance is immutable.
Much better than the proxy approach!!
:-)
Then, you can pass in the DefaultImmutableConfiguration to
any client that expects to hold on to a reference for ever and ever,
and you can just pass your regular MutableConfiguration to
the methods that just require the configuration not to change at all.
I've parsed the above sentence multiple times and I'm still in trying to figure out what this means.
Note regarding the name: Yes, I know that we should have:
class DefaultConfiguration implements Configuration
and:
class DefaultMutableConfiguration extends DefaultConfiguration implements MutableConfiguration
and not the thing I proposed:
class DefaultConfiguration implements MutableConfiguration
class DefaultImmutableConfiguration implements Configuration
But I can't do it the proper way due to backwards compat.
So in effect we have DefaultConfiguration which in practice is a DefaultMutableConfiguration and we have a utility class DefaultImmutableConfiguration which is a immutable copy. Sounds fine to me.
One thing that comes out of the is the pain associated with publication of implementation classes. In the future I would like to see a general practice of maintaining flexibility with respect to published implementations - they should be able to change as we need to - whereas api contracts should be the reference for backward compatibility concerns.
Cheers, Steve.
/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]
