On 16 October 2010 06:18, Simone Tripodi <simone.trip...@gmail.com> wrote: > yes, understood and agreed. > BTW I still find redundant that the same field, used with the same > semantic, is present in Config,Pool and Factory, my proposal was about > keeping the Config only - immutable fields can be declared there - and > remove config parameters from Factory/Pool, that will require a Config > or use the default one.
I'd be happy with using config for all parameters. If one did not want to have multiple config constructors for them, then immutable fields could be extracted from the config by the Factory (etc.) constructors. The Factory class would then use its local final copy of the immutable field, and subsequent changes to the config would be ignored. This would be fairly easy to implement, but the different treatment of some config parameters would need to be documented. > Otherwise any suggestion is much more than welcome, it would be a > shame IMHO not improving the design. > Thanks for discussing about this topic, have a nice day, > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Sat, Oct 16, 2010 at 2:25 AM, sebb <seb...@gmail.com> wrote: >> On 15 October 2010 17:01, Simone Tripodi <simone.trip...@gmail.com> wrote: >>> Hi all guys, >>> there are Generic(Keyed)ObjectPool(Factory) that (in pairs, Pool and >>> related factory) share the same kind of information, replicated in the >>> related Config class. >>> >>> I wonder if we can improve that design and remove that information >>> redundancy: I propose to keep the Config classes only, put them not as >>> inner class, in order to remove the circular dependency between >>> factory/pool and remove also the not so comfortable (at least for me) >>> n-arguments constructors. >>> So, the GenericObjectPool, instead of having all these constructors, >>> could work only with: >>> >>> public GenericObjectPool(PoolableObjectFactory<T> factory) { >>> this(factory, new Config()); >>> } >>> >>> public GenericObjectPool(PoolableObjectFactory<T> factory, Config config) { >>> this.factory = factory; >>> this.config = config; >>> } >>> >>> both factory and config can be final; if users need to reconfigure the >>> pool at runtime, invoke the setter and modify the interested value >>> >>> pool.getConfig().setWhenExhaustedAction(WhenExhaustedAction.GROW); >>> >>> I'd extend later the same approach also to other Pools... WDYT? >> >> The advantage of using ctor parameters is that they can be saved in a >> final field. >> The config approach is OK for parameters that need to remain mutable, >> but can impose additional synch. requirements for settings that must >> not be changed during the life of the pool. >> >> For example, I suspect LIFO should be immutable, and should therefore be >> final. >> >>> Many thanks in advance, >>> Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
