commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: [pool] Pool, Factory and Config
Date Sat, 16 Oct 2010 12:10:30 GMT
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 <sebbaz@gmail.com> wrote:
> On 16 October 2010 06:18, Simone Tripodi <simone.tripodi@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 <sebbaz@gmail.com> wrote:
>>> On 15 October 2010 17:01, Simone Tripodi <simone.tripodi@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message