returning false from Collection.add()

Discussion in 'Java' started by VisionSet, Dec 3, 2003.

  1. VisionSet

    VisionSet 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
    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

    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.
    VisionSet, Dec 3, 2003
    1. Advertisements

  2. VisionSet

    Guest Guest

    You _ARE_ creating a set, just using a different criteria as to what makes
    Objects sufficiently unique.
    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.

    La'ie Techie
    Guest, Dec 3, 2003
    1. Advertisements

  3. VisionSet

    VisionSet Guest

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

    VisionSet, Dec 4, 2003
  4. 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
    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.
    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
    John C. Bollinger, Dec 4, 2003
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.