Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of simone.tripodi@gmail.com
 designates 74.125.82.49 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=eSN7VLchJchPUJZCDu72B5ZQjExuEtgpqYPqQqdc2zhjlepCUcHh2frm+W/ov42seQ
         53LGmi+S9P5M0iD/mTVN/QsRe9NxrPiXijk5EWnfqtCDtDwSSm6rgEb2O8hyc0q3+VKB
         WDeScJc3cS+RWU4Wj1gCiwzA9Kycr02DuuVQs=
MIME-Version: 1.0
In-Reply-To: <4CB46CA3.6030204@apache.org>
References: <4CB462A3.30803@gmail.com>
	<AANLkTikY3AJKxFZBrpAPWZ4=htq390ooZN6GbFSnB3di@mail.gmail.com>
	<AANLkTinUm8tOb=iMyC6uTcgj46Pkd5Ppop6gsp21dChA@mail.gmail.com>
	<4CB46CA3.6030204@apache.org>
Date: Tue, 12 Oct 2010 16:17:10 +0200
Message-ID: <AANLkTimcYheX34=UyhJe=b3txOvxQPFe3-sNKzdewcQx@mail.gmail.com>
Subject: Re: [POOL] generics on KeyedObjectPool
From: Simone Tripodi <simone.tripodi@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi James, Mark,
Being honest, I've never experienced using the keyed pool to store
multiple types too, I've always used different instances to store
multiple types to avoid get confused, otherwise it would be very easy
- at least to me - get trapped in a Tower of Babel.
I agree with you on keeping the APIs simple and straightforward.
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/


On Tue, Oct 12, 2010 at 4:11 PM, Mark Thomas <markt@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? =C2=A0I've never really seen that in practice, but I guess=
 it
>> could happen. =C2=A0Just 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.tripodi@gmail.com> wrote:
>>> Hi Brent!
>>> sounds reasonably good, the only worry I've on it is about the method
>>>
>>> =C2=A0 =C2=A0<V> V borrowObject(K key);
>>>
>>> because I don't know the type of V; speaking in therms of examples:
>>>
>>> =C2=A0 =C2=A0new MyKeyedObjectPoolImpl<String>().borrowObject("one") =
=3D ???
>>>
>>> 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.worden@gmail.com> =
wrote:
>>>> =C2=A0The javadoc on KeyedObjectPool states 'A keyed pool pools instan=
ces of
>>>> multiple types.' =C2=A0However, the new parametrization on KeyedObject=
Pool allows
>>>> for only a single instance type.
>>>>
>>>> To allow for pooling multiple typed instances, should the instance typ=
e
>>>> parameter be removed from the interface declaration and placed on the
>>>> relevant method declarations? =C2=A0In 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-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