I agree that it is desirable to reduce mutability.
Most of the collections returned from any definition
class could be made immutable.
A call to Collections.unmodifiableCollection() would solve this.
Regarding the addXxx methods I find it very helpful to use
the definition classes for construction and extension resolving.
Otherwise one would need an additional structure that represents
the assocations between extension points and extensions and which
is used during construction for resolving and constraint checking.
To my mind it feels like the most natural fit to add and retrieve
the associated objects directly from their source.
These add methods are defined in the public interfaces.
RegistryDefinition#addModule
RegistryDefinition#addPostProcessor
RegistryDefinition#addRegistryInitializationListener
ModuleDefinition#addServicePoint
ModuleDefinition#addConfigurationPoint
...
ConfigurationPointDefinition#addContribution
ConfigurationPointDefinition#addParser
ServicePointDefinition#addImplementation
ServicePointDefinition#addInterceptor
Although it might be possible to shift some of them to the
the implementation classes, at least
the add-methods of RegistryDefinition and ModuleDefinition must remain.
So, to achieve immutability in a consistent manner I would suggest
to use the same mechanism that is implemented in
RegistryInfrastructureImpl.
After the startup of the registry the definition classes gets locked, that
means further modification by calls to the add methods are forbidden.
This requirement must be document in the interfaces and could be
implemented
in the default implementation of the definition interfaces.
I don't expect this to make the implementation of the API more difficult
in any way, Knut.
Please take a look at the current implementations of the api: the xml
module specializes
2 classes of the default implementation only and the annotation module
doesn't override
any implementation at all. Most of the stuff is handled by the
constructors.
I don't think that a spring implementation would require special
implementations
of the api which cannot be inherited from the default implementation.
How do you expect the api to get simpler? Could you give an example?
Achim
Am Wed, 24 Jan 2007 16:59:31 +0100 schrieb Knut Wannheden
<[EMAIL PROTECTED]>:
Hi all,
I just took a look at the new registry construction API in the 2.0
proposal. I think it looks very good but one thing I'd like to discuss
is the mutability requirements. I'm talking about the various addXxx()
methods and the fact that some Collection objects returned by some
getters must be mutable. Specifically I'd like to discuss if the
mutability in the API is needed and / or desired.
From what I can work out the mutability of the module definitions is
used by HiveMind for the following things:
1. Module definition construction -- The actual implementations of the
API can use the addXxx() methods to construct the actual module
definition.
2. Merging "hivemind" module definition -- If the user is using the
optional XML support in HiveMind then HiveMind will during registry
construction merge definitions for the "hivemind" module from the
hivemodule.xml file in the XML module with the plain Java definitions
in the framework module. (Note that this is a specific case of the
former usage described.)
3. Extension resolving -- During registry construction HiveMind will
"move" any extensions (service implementations, service interceptors,
contributions, and the new configuration parsers) which have been
registered at the module level to the appropriate extension point by
removing it from the respective module's collection (returned by a
getXxx() method) and add it to the extension using an addXxx() method.
I hope I didn't miss anything now.
IMHO it would be great if we could drop the mutability requirements
and thus both simplify the API and make it easier to write an
implementation for it. One use case I had in mind is something James
mentioned: mapping a Spring application context to a HiveMind module.
Any other opinions on this one?
Regards,
--knut
