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? 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*? Should we engrave it in Avalon spi? Have there been any concerns on Merlin footprint? Anton > > /LS > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
