On Tue, Mar 16, 2010 at 11:06 AM, Alejandro Rodriguez
<l.mephi...@gmail.com> wrote:
> Hello Clark,
>
> The objects in the set are NSObject subclasses that have a NSString readonly
> property (messageId) and are always initialized through initWithMessageId:
> where that value is set and never changed.
>
> The hash and isEqual methods are as follows:
>
> - (NSUInteger)hash{
> return (messageId == nil) ? [super hash]:[messageId hash];
> }
>
> - (BOOL)isEqual:(id)object{
> if([self messageId] == nil)return [super isEqual:object];
> if([object isKindOfClass:[RTMessage class]]){
> return [[self messageId] isEqualToString:[object messageId]];
> }
> if([object isKindOfClass:[NSString class]]){
> return [[self messageId] isEqualToString:object];
> }
> return [super isEqual:object];
> }
>
>
> This basically allows me to do something like [messageSet member:@"123"] and
> return the object with ID 123 or [memberSet member:messageObject] and have
> the same result.
Your code doesn't account for the possibility that the order of
comparison might happen in the other order (i.e. [@"123" isEqual:
object]). I wouldn't be surprised if NSSet is assuming that equality
is transitive (i.e. [a isEqual: b] == [b isEqual: a]).
> This is the first condition I checked when the problem started presenting
> itself but since messageId is readonly and retained
Is it "retain" or "copy"? It really should be the latter. If there's
any chance that the object is ever initialized with an NSMutableString
the difference is important.
> then it shouldn't ever change through the lifetime of the object once created
> and added to the set. This is the condition that the docs say must be ensured.
>
> Thanks for your response,
>
> Alejandro Rodríguez
> On Mar 16, 2010, at 1:46 PM, Clark Cox wrote:
>
>> On Tue, Mar 16, 2010 at 10:28 AM, Alejandro Rodriguez
>> <l.mephi...@gmail.com> wrote:
>>> Hello All,
>>>
>>> I am using NSMutableSet quite extensively in my app mostly just
>>> adding items to it and reading them (almost never removing). However
>>> sometimes it crashes under very interesting conditions. I can't reliable
>>> recreate the issue but sometimes I get a 'attempted to insert nil'
>>> exception when FILTERING the set using a predicate, if I breakpoint at this
>>> exception and print the set description I see that it has many valid
>>> objects but also a bunch of nil (null) objects which doesn't make any sense
>>> since I can't insert nil objects to the set in the first place!
>>>
>>> I can't think of any scenario where I can insert nil objects to the
>>> set or insert a valid object which would then point nil. My app is
>>> multi-threaded and the set is accessed in @sychronized blocks from many
>>> threads all the time.
>>>
>>> Has anyone had a similar problem? am I missing something? is it a
>>> bug with the foundation object?
>>
>>
>> What kind of objects are in the set? What do their -isEqual: and -hash
>> methods look like? Is there any possibility that objects in that set
>> are changed in a way that affects the results returned by their
>> -isEqual: and/or -hash methods?
>>
>> --
>> Clark S. Cox III
>> clarkc...@gmail.com
>
>
--
Clark S. Cox III
clarkc...@gmail.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
