> a) Where does it belong?
Can we solve this by a simple majority vote?
1. avalon-framework-api
2. avalon-framework-spi
3. avalon-framework-impl
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.
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?
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.
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.
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.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
