returning false from Collection.add()

[VisionSet]

Having read the API docs for Collection.add
What are the pitfalls, when my implementation decides not to add for its own
reasons and returns false.

My Collection disallows 'overlapping' objects, that is not to say they are
Object.equal
So I'm not creating a kind of Set.
There is only one way equals can be implemented (for any one class) compared
with (forgive pun) compare(), which can be implemented in many ways via
Comparator.

If I could have multiple equals methods I could have any 'overlapping'
object is equal equals().
But there isn't and there isn't a:

java.util.Set.add(Object obj, Comparator comp)

on which to judge object equality.

 

[Guest]

Having read the API docs for Collection.add What are the pitfalls, when my
implementation decides not to add for its own reasons and returns false.

My Collection disallows 'overlapping' objects, that is not to say they are
Object.equal
So I'm not creating a kind of Set.

You _ARE_ creating a set, just using a different criteria as to what makes
Objects sufficiently unique.

There is only one way equals can be implemented (for any one class)
compared with (forgive pun) compare(), which can be implemented in many
ways via Comparator.

If I could have multiple equals methods I could have any 'overlapping'
object is equal equals().
But there isn't and there isn't a:

java.util.Set.add(Object obj, Comparator comp)

on which to judge object equality.

Wouldn't you want to use the same Comparator for all items in the Set?

Check out java.util.TreeSet to see if it meets your needs.

Aloha,
La'ie Techie

 

[VisionSet]

Wouldn't you want to use the same Comparator for all items in the Set?

Check out java.util.TreeSet to see if it meets your needs.

Ahh!! A TreeX class, first time for everything, look Mum...

Cheers.

 

[John C. Bollinger]

Having read the API docs for Collection.add
What are the pitfalls, when my implementation decides not to add for its own
reasons and returns false.

The only potential pitfall I see is with code that neglects to check the
return value of add(Object) and just assumes that the attempted addition
succeeded.

My Collection disallows 'overlapping' objects, that is not to say they are
Object.equal
So I'm not creating a kind of Set.

Assuming that an object always overlaps itself, you are indeed creating
a set in the mathematical sense (as our Hawaiian friend already pointed
out) -- a more restrictive one than the general purpose versions
provided in the platform API. As you seem to be observing, however,
your set violates the general Set contract with respect to the
add(Object) method [and dependant methods]. It therefore should not
implement Set, even though it looks and feels a lot like one.

There is only one way equals can be implemented (for any one class) compared
with (forgive pun) compare(), which can be implemented in many ways via
Comparator.

If I could have multiple equals methods I could have any 'overlapping'
object is equal equals().
But there isn't and there isn't a:

java.util.Set.add(Object obj, Comparator comp)

on which to judge object equality.

Java Collections are inherently based on Object.equals(). If you only
need to worry about overlaps at object addition time then you can
probably do well by implementing the Collection interface directly,
perhaps with the help of AbstractCollection. If, however, you
anticipate a need to take overlaps into account elsewhere -- in contains
or remove functionality, for instance -- then you might be better off
just building your own. You could use one or another type of Collection
internally, if you wanted, but your class itself would have some
fundamental differences from a Java Collection.

If you were ambitious you might write a generalization of the
Collections API that could handle this sort of thing with a configurable
policy object that served the place of Object.equals().


John Bollinger
(e-mail address removed)