You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2011/09/11 20:29:43 UTC
[pool] drop Base(Keyed)ObjectPool?
These classes really do nothing other than maintain the boolean
"closed", throwing UnsupportedOperationException or returning
nonsense for most methods. The interfaces define contracts, so why
do we really need these base classes?
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] drop Base(Keyed)ObjectPool?
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Sep 11, 2011 at 4:36 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 9/11/11 12:44 PM, Gary Gregory wrote:
> > Perhaps we want to keep the ivars in one place since they all have very
> > carefully been decorated with final and volatile just in the right
> places?
>
> There is only one field being maintained and I think it would
> actually be clearer to push it into the (small number of) remaining
> impls.
>
> >
> > What about dropping "Object" from the name? That makes even less sense
> now
> > that we have generics enabled.
>
> Well, generic or no, what we pool r objects ;)
>
As opposed to what? Primitives? ;) Seriously, it seems superfluous.
I thought the name originated in the fact that the pool was typed to use
java.lang.Object as opposed to more specific types. The name could be
justified in my mind then, but not with the use of generics.
My 2c,
Gary
>
> Phil
> >
> > Gary
> >
> > On Sun, Sep 11, 2011 at 2:29 PM, Phil Steitz <ph...@gmail.com>
> wrote:
> >
> >> These classes really do nothing other than maintain the boolean
> >> "closed", throwing UnsupportedOperationException or returning
> >> nonsense for most methods. The interfaces define contracts, so why
> >> do we really need these base classes?
> >>
> >> Phil
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: http://s.apache.org/rl
Spring Batch in Action: http://s.apache.org/HOq
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [pool] drop Base(Keyed)ObjectPool?
Posted by ma...@apache.org.
Phil Steitz <ph...@gmail.com> wrote:
>On 9/11/11 12:44 PM, Gary Gregory wrote:
>> Perhaps we want to keep the ivars in one place since they all have
>very
>> carefully been decorated with final and volatile just in the right
>places?
>
>There is only one field being maintained and I think it would
>actually be clearer to push it into the (small number of) remaining
>impls.
+1 - happy to see them go
>>
>> What about dropping "Object" from the name? That makes even less
>sense now
>> that we have generics enabled.
>
>Well, generic or no, what we pool r objects ;)
Object pools make sense to me but I'm not wedded to the name.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] drop Base(Keyed)ObjectPool?
Posted by Phil Steitz <ph...@gmail.com>.
On 9/11/11 12:44 PM, Gary Gregory wrote:
> Perhaps we want to keep the ivars in one place since they all have very
> carefully been decorated with final and volatile just in the right places?
There is only one field being maintained and I think it would
actually be clearer to push it into the (small number of) remaining
impls.
>
> What about dropping "Object" from the name? That makes even less sense now
> that we have generics enabled.
Well, generic or no, what we pool r objects ;)
Phil
>
> Gary
>
> On Sun, Sep 11, 2011 at 2:29 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>> These classes really do nothing other than maintain the boolean
>> "closed", throwing UnsupportedOperationException or returning
>> nonsense for most methods. The interfaces define contracts, so why
>> do we really need these base classes?
>>
>> Phil
>>
>> ---------------------------------------------------------------------
>> 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
Re: [pool] drop Base(Keyed)ObjectPool?
Posted by Phil Steitz <ph...@gmail.com>.
On 9/19/11 1:08 AM, Jörg Schaible wrote:
> Phil Steitz wrote:
>
>> On 9/18/11 2:43 PM, Gary Gregory wrote:
>>> Sure. I was under the Impression that 2 subclasses reused the fields.
>> Well, they (GOP, GKOP and others) do use the closed field; but IMO
>> that is not enough justification for the complexity of having them
>> there and the ugliness of the UnsupportedOperationExceptions and
>> nonsense values returned in the base implementations of pool stats.
>> So, I will go ahead and remove the base classes.
> Or simply use abstract classes and keep only the relevant code?
That would make sense if there were a nontrivial amount of useful
code to keep or if we wanted to get rid of the interfaces. I don't
see either of those as compelling. Do you?
Phil
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> 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
Re: [pool] drop Base(Keyed)ObjectPool?
Posted by Jörg Schaible <jo...@scalaris.com>.
Phil Steitz wrote:
> On 9/18/11 2:43 PM, Gary Gregory wrote:
>> Sure. I was under the Impression that 2 subclasses reused the fields.
>
> Well, they (GOP, GKOP and others) do use the closed field; but IMO
> that is not enough justification for the complexity of having them
> there and the ugliness of the UnsupportedOperationExceptions and
> nonsense values returned in the base implementations of pool stats.
> So, I will go ahead and remove the base classes.
Or simply use abstract classes and keep only the relevant code?
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] drop Base(Keyed)ObjectPool?
Posted by Phil Steitz <ph...@gmail.com>.
On 9/18/11 2:43 PM, Gary Gregory wrote:
> Sure. I was under the Impression that 2 subclasses reused the fields.
Well, they (GOP, GKOP and others) do use the closed field; but IMO
that is not enough justification for the complexity of having them
there and the ugliness of the UnsupportedOperationExceptions and
nonsense values returned in the base implementations of pool stats.
So, I will go ahead and remove the base classes.
Phil
>
> Gary
>
> On Sep 18, 2011, at 17:39, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 9/11/11 12:44 PM, Gary Gregory wrote:
>>> Perhaps we want to keep the ivars in one place since they all have very
>>> carefully been decorated with final and volatile just in the right places?
>> Given that there is only one field being maintained, are you OK with
>> dropping these, Gary?
>>
>> Phil
>>> What about dropping "Object" from the name? That makes even less sense now
>>> that we have generics enabled.
>>>
>>> Gary
>>>
>>> On Sun, Sep 11, 2011 at 2:29 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>
>>>> These classes really do nothing other than maintain the boolean
>>>> "closed", throwing UnsupportedOperationException or returning
>>>> nonsense for most methods. The interfaces define contracts, so why
>>>> do we really need these base classes?
>>>>
>>>> Phil
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
Re: [pool] drop Base(Keyed)ObjectPool?
Posted by Gary Gregory <ga...@gmail.com>.
Sure. I was under the Impression that 2 subclasses reused the fields.
Gary
On Sep 18, 2011, at 17:39, Phil Steitz <ph...@gmail.com> wrote:
> On 9/11/11 12:44 PM, Gary Gregory wrote:
>> Perhaps we want to keep the ivars in one place since they all have very
>> carefully been decorated with final and volatile just in the right places?
>
> Given that there is only one field being maintained, are you OK with
> dropping these, Gary?
>
> Phil
>>
>> What about dropping "Object" from the name? That makes even less sense now
>> that we have generics enabled.
>>
>> Gary
>>
>> On Sun, Sep 11, 2011 at 2:29 PM, Phil Steitz <ph...@gmail.com> wrote:
>>
>>> These classes really do nothing other than maintain the boolean
>>> "closed", throwing UnsupportedOperationException or returning
>>> nonsense for most methods. The interfaces define contracts, so why
>>> do we really need these base classes?
>>>
>>> Phil
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: [pool] drop Base(Keyed)ObjectPool?
Posted by Phil Steitz <ph...@gmail.com>.
On 9/11/11 12:44 PM, Gary Gregory wrote:
> Perhaps we want to keep the ivars in one place since they all have very
> carefully been decorated with final and volatile just in the right places?
Given that there is only one field being maintained, are you OK with
dropping these, Gary?
Phil
>
> What about dropping "Object" from the name? That makes even less sense now
> that we have generics enabled.
>
> Gary
>
> On Sun, Sep 11, 2011 at 2:29 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>> These classes really do nothing other than maintain the boolean
>> "closed", throwing UnsupportedOperationException or returning
>> nonsense for most methods. The interfaces define contracts, so why
>> do we really need these base classes?
>>
>> Phil
>>
>> ---------------------------------------------------------------------
>> 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
Re: [pool] drop Base(Keyed)ObjectPool?
Posted by Gary Gregory <ga...@gmail.com>.
Perhaps we want to keep the ivars in one place since they all have very
carefully been decorated with final and volatile just in the right places?
What about dropping "Object" from the name? That makes even less sense now
that we have generics enabled.
Gary
On Sun, Sep 11, 2011 at 2:29 PM, Phil Steitz <ph...@gmail.com> wrote:
> These classes really do nothing other than maintain the boolean
> "closed", throwing UnsupportedOperationException or returning
> nonsense for most methods. The interfaces define contracts, so why
> do we really need these base classes?
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: http://s.apache.org/rl
Spring Batch in Action: http://s.apache.org/HOq
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [pool] drop Base(Keyed)ObjectPool?
Posted by Simone Tripodi <si...@apache.org>.
full support from my side on it, +1
I never understood the usefulness of these classes and they don't help
on writing concrete pool implementations.
Have a nice day, all the best!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Sep 11, 2011 at 8:29 PM, Phil Steitz <ph...@gmail.com> wrote:
> These classes really do nothing other than maintain the boolean
> "closed", throwing UnsupportedOperationException or returning
> nonsense for most methods. The interfaces define contracts, so why
> do we really need these base classes?
>
> Phil
>
> ---------------------------------------------------------------------
> 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