I'm good with a pool consisting of one type of object
On Tue, Oct 12, 2010 at 10:11 AM, Mark Thomas <ma...@apache.org> wrote:
> On 12/10/2010 15:03, James Carman wrote:
>> Is it really realistic to think that a pool would support multiple
>> object types? I've never really seen that in practice, but I guess it
>> could happen. Just seems weird to me.
>
> +1. I'm having a hard time coming up with a use case where those objects
> wouldn't support some common interface. And if that interface is Object,
> just declare a pool of type Object.
>
> Lets not make things more complicated than they need to be.
>
> Mark
>
>>
>>
>> On Tue, Oct 12, 2010 at 9:49 AM, Simone Tripodi
>> <simone.trip...@gmail.com> wrote:
>>> Hi Brent!
>>> sounds reasonably good, the only worry I've on it is about the method
>>>
>>> <V> V borrowObject(K key);
>>>
>>> because I don't know the type of V; speaking in therms of examples:
>>>
>>> new MyKeyedObjectPoolImpl<String>().borrowObject("one") = ???
>>>
>>> So the APIs have to be improved following the Jame's suggestions.
>>> Have a nice day!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Tue, Oct 12, 2010 at 3:29 PM, Brent Worden <brent.wor...@gmail.com>
>>> wrote:
>>>> The javadoc on KeyedObjectPool states 'A keyed pool pools instances of
>>>> multiple types.' However, the new parametrization on KeyedObjectPool
>>>> allows
>>>> for only a single instance type.
>>>>
>>>> To allow for pooling multiple typed instances, should the instance type
>>>> parameter be removed from the interface declaration and placed on the
>>>> relevant method declarations? In other words, replace:
>>>>
>>>> public interface KeyedObjectPool<K,V> {
>>>> ...
>>>> }
>>>>
>>>> with:
>>>>
>>>> public interface KeyedObjectPool<K> {
>>>>
>>>> <V> V borrowObject(K key);
>>>>
>>>> <V> void invalidateObject(K key, V obj);
>>>>
>>>> <V> void returnObject(K key, V obj);
>>>> ...
>>>> }
>>>>
>>>> Thoughts?
>>>>
>>>> Brent.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
