Hello, guys!
Farr> b) Should MutableConfiguration extend
Farr> Configuration?
LSU> public class DefaultImmutableConfiguration
LSU> implements Configuration
LSU> {
LSU> DefaultImmutableConfiguration (Configuration config)
LSU> {
LSU> ...
LSU> }
LSU> }
LSU> The constructor will do a deep copy of the supplied
LSU> Configuration, thus ensuring that the instance is immutable.
The class looks usefull indeed.
One reservation nevertheless:
* the main use case is to allow different storage
structures behind MutableConfiguration
right?
* this is done to choose between
- faster
- low-memory-footprint
implementations depending on evironment
(desktop/server/Java2ME)
and size of configuration provisioned
right?
*IF* both answers are 'yes', then I'd prefer not to
deep-copy the configuration data unless it's unavoidable
If we want to conserve memory then I'd go about it like
once the container has passed configuration to client
that will hold on if for ever and ever, the container just
stops modifying it.
Thoughts?
Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
