Thanks for the feedbacks Seb!!! what about if I start implementing a proposal and then we progressively refine the design? Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Oct 16, 2010 at 1:46 PM, sebb <seb...@gmail.com> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
