Oh, thanks for the clarification, I missed that the mismatch was only
between put and add, not remove.
Still, wouldn't an "add" be more intuitive (for Java programmers) than
a put with inverted return value?
Btw, reading this code (JavaConversions.scala):
case class JSetWrapper[A](underlying : ju.Set[A]) extends
mutable.Set[A] with generic.MutableSetTemplate[A, JSetWrapper[A]] {
...
override def put(elem: A): Boolean = underlying.add(elem)
I would expect to see a negation there. Right? Or did I miss something again?
2009/5/19 martin odersky <
martin.odersky@...>:
> On Tue, May 19, 2009 at 12:42 PM, Jim Andreou <
jim.andreou@...> wrote:
>> I see these two methods on sets:
>>
>> xs put x : Adds element x to xs and returns whether x was previously
>> contained in the set.
>> xs remove x : Removes element x from xs and returns whether x was
>> previously contained in the set.
>>
>> The semantics of the return values is the opposite of the analogous
>> methods of java.util.Collection#{add, remove}, is this intentional?
>> This is bound to create some confusion...
>
> Not true. Remove is the same as for Java. Put is the same as for
> Java's map put, if you equate true with "object returned" -- this
> equation holds for remove in any case. Put is different from Set.add
> in Java, but then their names are different, too.
>
> Cheers
>
> -- Martin
>
