> From: Anton Tagunov [mailto:[EMAIL PROTECTED] > > Hi, Leo! > > Really like it to talk fast :) > > AT> * the main use case is to allow different storage > AT> structures behind MutableConfiguration > AT> > AT> right? > > LSU> No. The purpose is to allow an application to code against an > LSU> interface (MutableConfiguration) instead of against a concrete > LSU> class (DefaultConfiguration). > > But why do we want it? > > MutableConfiguration impl is *only* about *storing* data. > So, why abstract it? > Only to allow different storage strategies. > > Right?
Not as much *allow* different storage strategies as to not have to make the strategy explicit. It's splitting hairs, but... "I don't want to swap out the storage strategy, and I don't want to care about it." So, I want MutableConfiguration not so much because I want to write another implementation of it, but because I don't want to use a concrete class in my code when an interface will do. Of course, this means that we *can* allow other implementations, but this is not the primary reason for me. > LSU> The deep-copy is done when you absolutely, positively > LSU> have to ensure that a configuration is immutable. > > Right. I like the approach. The class is useful. > > But should we really apply this patter *always*? No. Use it when it makes sense. > Should we engrave it in Avalon spi? The class will go into -impl. > Have there been any concerns on Merlin footprint? Since Merlin has complete control over the configuration objects, it will probably not even use the class. If a component wants to mess up *its own* configuration, it is free to do so. /LS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
