commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: [Pool] What's left for a release?
Date Tue, 22 Apr 2003 17:44:14 GMT

Howdy,
I'll jump in as a simple user of this code but having faced this problem
numerous times as a contributor on several jakarta and for-profit
projects.

>(1) Which exact one field in GenericObjectPool would we need to change
to
>protected access to address our current problem? We could make this one
>field protected in 2.0. We could then create our own subclass and
define
>the
>behavior we need. You would end up with GenericObjectPool that has one
ivar
>protected and all others private, which is oddly inconsistent and needs
to

I don't think it's oddly inconsistent.  In fact, I think it's consistent
with the practice of making everything private until an overriding
requirement comes up.  However, I agree with you this approach is
suboptimal.

>Well, we would like to be implementing our own pool to customize
behavior
>in GenericObjectPool, but we cannot. Hence the request to simply make
>fields and methods that are now private protected. This would allow
>subclassing to work, always. Why not solve this problem once?

I agree this would be a better long-term solution conceptually.  Two
points though:
- Not all private fields should automatically be made protected.  Only
those fields likely to be modified by a subclass need be made protected.

- There's a conflicting requirement here, which is a speedy release to
satisfy struts dependencies.

Given the speedy release requirement, I would tend to say keep it as
stable as possible, and make the private->protected transition one of
the top items for the next release.  Of course that's easy for me to say
as I don't need the modifications right now.  However, I would
anticipate a fairly quick (< 4 weeks) Pool 2.1 release with mainly these
modifications.

Yoav Shapira
Millennium ChemInformatics



This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.


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


Mime
View raw message