On 6 February 2015 at 19:19, James Carman <ja...@carmanconsulting.com> wrote: > I guess you mean we would wrap around any object type and give it > (back) this functionality, so they don't have to change their > equals/hashCode impls.
Yes. Of course anyone can do the wrapping themselves, which should be a bit more efficient (no need to create a wrapper each time), but is not as easy to use. The idea is to provide a convenience class which behaves more like Pool1. If the gift-wrapping service proves too expensive, the caller can pre-prepare their own objects. > On Fri, Feb 6, 2015 at 2:09 PM, James Carman <ja...@carmanconsulting.com> > wrote: >> Or, you just don't implement equals()/hashCode() and you get that >> functionality for free, right? >> >> On Fri, Feb 6, 2015 at 1:56 PM, sebb <seb...@gmail.com> wrote: >>> There seem to be a few use-cases for pools that always treat different >>> instances as different entries, rather than using the current equals() >>> check. >>> >>> Would it make sense to implement alternative versions that accept an >>> object and wrap it in a class that implements equals() using == and >>> System.identityHashcode? >>> >>> The IdentityWrapper class was suggested here: >>> >>> https://issues.apache.org/jira/browse/POOL-283?focusedCommentId=14307637&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14307637 >>> >>> I think it could be done by subclassing the existing implementations >>> to provide the wrapping/unwrapping support. >>> >>> There would be an overhead because the wrappers would need to be >>> created every time an object was passed in. The wrappers are very >>> small. >>> >>> S. >>> >>> --------------------------------------------------------------------- >>> 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
