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
