Hi James, thanks for the feedback!!!! Guys, please review r1021756, I introduced a WhenExhaustedAction enumeration that's shared between all Generic(Keyed)?ObjectPool(Factory)? components. I also removed the useless TestGenericObjectPool.testInvalidWhenExhaustedAction() since WhenExhaustedAction is already value-safety
Does it work for you? Please let me know! Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Oct 12, 2010 at 1:40 PM, James Carman <ja...@carmanconsulting.com> wrote: > +1 to enums > > On Tue, Oct 12, 2010 at 7:34 AM, Simone Tripodi > <simone.trip...@gmail.com> wrote: >> Hi Mark, >> thank a lot for your feedback! I agree with your POV, since we're >> using Java1.5 we should take advantage of the whole provided features >> :) >> Thanks! >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Tue, Oct 12, 2010 at 1:23 PM, Mark Thomas <ma...@apache.org> wrote: >>> On 12/10/2010 10:32, Simone Tripodi wrote: >>>> Hi all, >>>> following Phil's suggestion to point out candidates for deprecation / >>>> removal, I notice that both GenericObjectPool and >>>> GenericObjectPoolFactory share WHEN_EXHAUSTED_* properties of type >>>> byte to discriminate the action to perform when the pool is exhausted. >>>> Do you agree on replacing byte with enums? I mean, in therms of >>>> design, IMHO is much more elegant having something like: >>>> >>>> enum WHEN_EXHAUSTED_ACTION = { BLOCK, FAIL, GROW }; >>>> >>>> and at the same time provides to end users more clear API. >>>> WDYT? just let me know, have a nice day, >>> >>> +1. >>> >>> In general, I am in favour of taking advantage of any and all Java 1.5 >>> features that lead to cleaner, safer, more readable code. I'm also in >>> favour of removing as much unnecessary, unused, deprecated etc code as >>> possible. >>> >>> Mark >>> >>> --------------------------------------------------------------------- >>> 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
