调用NSSet的setByAddingX方法时，哪个集合的对象会赢得平局？

Question

I bring this up because objects that compare the same with isEquals: aren't necessarily identical. Some (many) objects only compare certain properties to determine equality.

That makes the exact behavior of the following NSSet methods important:

setByAddingObject:
setByAddingObjectsFromArray:
setByAddingObjectsFromSet:

The documentation does not specify what happens when the receiver and the parameter contain equivalent objects. Will the resulting NSSet contain the object from the receiver, or the object from the "other" parameter?

Note that in NSMutableSet, it DOES specify the behavior of its add methods--objects will NOT be added if an "equal" object already exists in the set.

Answer 1

The documentation of NSMutableSet's addObject: method used to cover a similar case:

If anObject is already present in the set, this method has no effect on either the set or anObject .

But, as you can see from following the link, the current version doesn't even say that. And even that statement really only covers trying to add the same object; it does not specifically address adding a different but equal object.

Relying on observed but not documented behavior is dangerous, not just because it can change between OS versions, but also because it can change within the very same process. That's because NSSet is a class cluster , meaning there may be multiple implementations. Which one you get depends on how you create the set; there is no way to ensure that a specific implementation will be chosen or even exist.*

That's because it shouldn't matter. Every one of the clustered subclasses presents the same behavior as defined in the cluster's interface and documentation. (If it ever doesn't, that's a bug and you should report it .) Given that all the subclasses do effectively the same things, it shouldn't matter which one you get an instance of.

The same principle applies to your objects. They're equal! For that reason, it shouldn't matter which one is in the set. If it does matter, then they are not truly equal, and you need to make the objects' definition of equality more rigid. (Don't forget to update both isEqual: and hash .)

Depending on what you're using the set for, you may want to take that even farther and ensure that no two equal objects can exist. To do this, move the ownership, maintenance, and use of the set into the member objects' class, and have it always return a matching object instead of creating a new one whenever possible and appropriate.

*And even if you could choose one of the implementations, there's no guarantee that it'd have the behavior you observed forever—it could, and Murphy says probably will, be different in another OS version.

Answer 2

I tested this with the following code. SomeClass is defined such that propertyA is the only property considered in hash and isEquals:

SomeClass *objectA = [[[SomeClass alloc] init] autorelease];
objectA.propertyA = @"test";
objectA.propertyB = @"objectA";

SomeClass *objectB = [[[SomeClass alloc] init] autorelease];
objectB.propertyA = @"test";
objectB.propertyB = @"objectB";

NSSet *setA = [NSSet setWithObject:objectA];
NSSet *setB = [NSSet setWithObject:objectB];
NSSet *setC = [setA setByAddingObjectsFromSet:setB];

NSLog(@"Set A\n%@", [setA description]);
NSLog(@"Set B\n%@", [setB description]);
NSLog(@"Set C\n%@", [setC description]);

The output when running this code is:

2011-03-03 16:35:15.041 temp[50311:207] Set A
{(
    {SomeClass propertyA:test propertyB:objectA}
)}
2011-03-03 16:35:15.041 temp[50311:207] Set B
{(
    {SomeClass propertyA:test propertyB:objectB}
)}
2011-03-03 16:35:15.042 temp[50311:207] Set C
{(
    {SomeClass propertyA:test propertyB:objectA}
)}

This demonstrates that the newly created NSSet will contain objects from the RECEIVER in the case that the parameter contains equivalent objects.

EDIT - I'm marking this as the answer, because it directly answers the question at hand. I would however, point out Peter's answer below and the concerns he voices. This behavior is undocumented and as such, while it's extremely unlikely these core classes will change in this regard, it's worth pointing out that risk. If you write code assuming this behavior it is possible that it will break in a future release. Caveat emptor.