On 2/8/15 5:55 PM, sebb wrote:
> On 8 February 2015 at 16:57, Phil Steitz wrote:
>> On 2/8/15 8:51 AM, sebb wrote:
>>> On 6 February 2015 at 22:36, Phil Steitz wrote:
On 2/6/15 1:28 PM, sebb wrote:
> On 6 February 2015 at 19:58, Phil Steitz wrote:
>> On 2/6/15 11:56 AM, sebb wrote:
On 8 February 2015 at 16:57, Phil Steitz wrote:
> On 2/8/15 8:51 AM, sebb wrote:
>> On 6 February 2015 at 22:36, Phil Steitz wrote:
>>> On 2/6/15 1:28 PM, sebb wrote:
On 6 February 2015 at 19:58, Phil Steitz wrote:
> On 2/6/15 11:56 AM, sebb wrote:
>> There seem to be a few use-case
On 2/8/15 8:51 AM, sebb wrote:
> On 6 February 2015 at 22:36, Phil Steitz wrote:
>> On 2/6/15 1:28 PM, sebb wrote:
>>> On 6 February 2015 at 19:58, Phil Steitz wrote:
On 2/6/15 11:56 AM, sebb wrote:
> There seem to be a few use-cases for pools that always treat different
> instances
On 6 February 2015 at 22:36, Phil Steitz wrote:
> On 2/6/15 1:28 PM, sebb wrote:
>> On 6 February 2015 at 19:58, Phil Steitz wrote:
>>> On 2/6/15 11:56 AM, sebb wrote:
There seem to be a few use-cases for pools that always treat different
instances as different entries, rather than usin
On 2/6/15 1:28 PM, sebb wrote:
> On 6 February 2015 at 19:58, Phil Steitz wrote:
>> On 2/6/15 11:56 AM, sebb 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.
>> Yes
>>> Would it m
On 6 February 2015 at 19:58, Phil Steitz wrote:
> On 2/6/15 11:56 AM, sebb 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.
>
> Yes
>>
>> Would it make sense to implement alternative
On Fri, Feb 6, 2015 at 2:30 PM, sebb wrote:
>
> 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.
>
>
On 2/6/15 11:56 AM, sebb 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.
Yes
>
> Would it make sense to implement alternative versions that accept an
> object and wrap it in a class th
On 6 February 2015 at 19:19, James Carman 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
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 wrote:
> Or, you just don't implement equals()/hashCode() and you get that
> functionality for free,
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 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.
>
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.ident
12 matches
Mail list logo
