> From: Niclas Hedhman [mailto:[EMAIL PROTECTED] > > LS, > Niclas wrote; > > > > WHAT is needed? > > > WHY is that needed? > > > HOW can such need be satisfied? > > > What are the CONSEQUENCES of such change? > > > What are the SEMANTICS surrounding such change? > > I am failing to see that "your making the case" is addressing > these concerns in particular,
Niclas, before digging into the MutableConfiguration issue, I suspect that we have some kind of communications failure that keeps damaging this discussion. Let me give you my view of it: I think the questions you raise are over-broad: If you have any questions regarding the proposal I *did* write, you are of course welcome to bring them up - but a blanket "please list all consequences of your proposal" is simply impossible to satisfy. I have listed the consequences I found relevant to the proposal, and if I missed one that you find relevant then I'm afraid you have to bring it up yourself. I also don't find your statement "I am failing to see that 'your making the case' is addressing these concerns in particular", without specifying just what it is I have missed, to be of any help. Fernando Padilla managed to read my proposal and walk away with a 100% correct picture of what I wanted - I simply cannot believe that *you'd* walk away with a 0% understanding of what I proposed. Unfortunately, you're not letting me know what I failed to communicate! I'd like to ask you to be more specific, because I find myself interpreting your questions as "I didn't understand a word, could you tell me everything again?" Frustrating for both of us, I'm sure. > What > "I am creating my own container and would benefit to use a > defined interface during the creation of the Configuration > object to be passed to the component." > > Why > "By having a interface defined in the Framework, a container > can choose to provide an extension mechanism for > collaborative construction of the Configuration object, which > would work identically on more than one container." Not quite. "I have code that currently pass around a DefaultConfiguration instance. I'd much rather pass around an interface, since the code really does not depend on it being a DefaultConfiguration, but rather only on it being a-Configuration-but-modifiable. I would like to express this in the code, by not passing around DefaultConfiguration instances, and pass around an interface that encapsulates the behavior of a modifiable configuration." "Since the DefaultConfiguration is the prime example of a modifiable configuration, I'd like it to implement this new interface, that I'll call MutableConfiguration. In order for it to do so, I need to put the interface in framework-api, framework-impl, or some other framework-xxx package that framework-impl depends on." > HOW, > I would like to see that the interface MutableConfiguration > DOES NOT extend Configuration, but has the same method > signatures so that the implementation class can implement > them both. That provides a better flexibility for the > container on how to go about the creation process. We (Avalon) have utility code that take Configurations as parameters. Making MutableConfiguration not extend Configuration would mean that it could not be used with that code, which seems like a waste to me. /LS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
