But now you are completely breaking My contact
My object is an database object
MyObject
{
id
name
}
MyObject is only equals if the id is the same
But now i want a TreeSet that orders by name (sometimes case is
important,sometimes not)
Those things are not the same!
I cant make my object equals on name.. That would break everything else!
And that is just not true
I know TreeSet is a special case, but thats the whole point it should always
just use the comparator with everything.
Then it is jus always clear.
if we revert it
HashSet.removeAll(TreeSet)
now suddenly the comparator of the TreeSet is used to remove things from the
HashSet
That is just plain weird and stupid.
johan
On Thu, Mar 5, 2009 at 18:41, Dave Schoorl <[email protected]> wrote:
> Sorry Pointbreak, I did not change the Comparators. They are identical to
> Johan's example. All I did was to add the equals() and hascode() methods,
> aligning the equals with the Comparator, as described by the specs.
>
> Indeed, maybe I am missing Johan's point. But early in this thread Johan
> described his point as "we have to know the implementations" and illustrated
> that with the Set-example. My point is that you don't have to know the
> implementations when all contracts are fulfilled correctly. And I tried to
> point out in his example, that the contracts are not fulfilled correctly.
>
> But now I think Johan tries to make the point that the TreeSet is useless
> given the contracts, because the Comparator and equals() method must be
> compatible. Or he tries to make the point that the TreeSet implementation is
> broken and the specification must be changed. I'm not sure. I can sympathize
> with both. But I am glad he pointed out the problems with TreeSet, because I
> wasn't aware of them.
>
>
>
> Pointbreak wrote:
>
>> Dave, you are missing the point completely. The issue raised by Johan is
>> that if you call TreeSet.removeAll(otherSet), then in some cases the
>> comperator/equals contract of otherSet is used, in other cases the
>> comperator/equals contract of the treeset. Which is a bit strange, and
>> even by Sun considered a bug (although low priority). You are just
>> making both comperators the same, which of course will not demonstrate
>> this problem. Make the comperator of the TreeSet use str.compareTo
>> instead of compareToIgnoreCase, while keeping your implementation of
>> MyObject the same, and you will have the same problem that Johan
>> illustrated.
>>
>> On Thu, 05 Mar 2009 16:51 +0100, "Dave Schoorl" <[email protected]>
>> wrote:
>>
>>
>>> I do understand your point. However you are dealing with multiple
>>> contracts and not all of them are satisfied. And sometimes contracts are
>>> conflicting and it is impossible to meet all contracts, but I believe this
>>> is not the case in your scenario.
>>>
>>> A TreeSet is an implementation of a Set and must obey the Set contract.
>>> Adding order to the Set should not break the Set contract, because if I have
>>> a Set, I should not be concerned with the implementation details (is it a
>>> TreeSet or a HashSet or whatever). I believe the Set contract takes
>>> precedence over the Comparator contract, but in your case, by providing an
>>> equals method to MyObject that is in line with the Comparator, there still
>>> is no problem. See the code below, where MyObject implements the equals
>>> method with by comparing case insensitive:
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
