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.
On Fri, Feb 6, 2015 at 2:09 PM, James Carman <[email protected]> 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 <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
