Hi, Leo! AT> But why do we want it?
AT> MutableConfiguration impl is *only* about *storing* data. AT> So, why abstract it? AT> Only to allow different storage strategies. AT> Right? LSU> Not as much *allow* different storage strategies as to LSU> not have to make the strategy explicit. It's splitting hairs, LSU> but... "I don't want to swap out the storage strategy, LSU> and I don't want to care about it." LSU> So, I want MutableConfiguration not so much because LSU> I want to write another implementation of it, but because LSU> I don't want to use a concrete class in my code when LSU> an interface will do. LSU> Of course, this means that we *can* allow other implementations, LSU> but this is not the primary reason for me. We're in concensus: we're abstracting interface to *make other implementations possible*. And all what these implementations may differ is is *storage strategy*. LSU> The deep-copy is done when you absolutely, positively LSU> have to ensure that a configuration is immutable. AT> Right. I like the approach. The class is useful. AT> But should we really apply this patter *always*? LSU> No. Use it when it makes sense. AT> Should we engrave it in Avalon spi? LSU> The class will go into -impl. AT> Have there been any concerns on Merlin footprint? LSU> Since Merlin has complete control over the configuration LSU> objects, it will probably not even use the class. If a component LSU> wants to mess up *its own* configuration, it is free to do so. I see it a bit different. Internals of any contianer may pass MutableConfiguration instances around a lot. This happens if part A adds some of the configuration and then part B alters it. I'm more after using it inside containers not only inside components. It's a legitimate usage, isn't it? It does not matter if it is -spi or -api. (I would choose -api, if I had a vote here, but count it as non-binding, I've been away too long ;-) In any case container internals will start using it. Some lifecycle extensions and such. And therefore we should not *lock our lifecycle extendsion and container utilities* into using the deep-copy strategy. Should we? Anton --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
