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

    --
    Mike W
     
    VisionSet, Dec 3, 2003
    #1
    1. Advertising

  2. On Wed, 03 Dec 2003 21:40:40 +0000, VisionSet wrote:

    > 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
     
    =?UTF-8?b?TMSByrtpZSBUZWNoaWU=?=, Dec 3, 2003
    #2
    1. Advertising

  3. VisionSet

    VisionSet Guest

    "La?ie Techie" <laie@wing_this_etsolutions.com> wrote in message
    news:...
    >
    > > 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.


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

    Cheers.
    --
    Mike W
     
    VisionSet, Dec 4, 2003
    #3
  4. VisionSet wrote:

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

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. André
    Replies:
    3
    Views:
    1,636
  2. Øyvind Isaksen
    Replies:
    1
    Views:
    1,011
    Øyvind Isaksen
    May 18, 2007
  3. Rajarshi

    0 == False but [] != False?

    Rajarshi, May 24, 2007, in forum: Python
    Replies:
    20
    Views:
    723
    Erik Max Francis
    May 30, 2007
  4. Chad Scharf
    Replies:
    3
    Views:
    932
    Chad Scharf
    Oct 18, 2007
  5. DJ
    Replies:
    3
    Views:
    972
Loading...

Share This Page