> On Feb 4, 2015, at 5:43 AM, Jonathan Mitchell <[email protected]> wrote:
> 
> 
>> On 4 Feb 2015, at 13:27, Roland King <[email protected]> wrote:
>> 
>> If I have an observation pattern which is set up, and the previous one torn 
>> down, in setXXX:(id)xxx like you do then my dealloc usually goes
>> 
>> [ self setXXX:nil ]
>> 
>> which both removes the observers and sets the property to nil so it doesn’t 
>> happen again. 
>> 
>> Your problem here seems to be that you’ve tied the property to the observers 
>> in the set, but you are removing the observers without nil’ing the property 
>> in dealloc, thus leaving yourself open to another setter getting called. 
> Thanks.
> 
> That approach does work in this case.
> I don’t particularly like it in general because (in the more generic 
> NSViewController case) it calls back into a core method generally used to 
> help setup an instance.
> Calling this in a habitual sense from -dealloc feels sort of wrong!
> 
>> 
>>> 
>>> Crucially I find that in this case after my subclass -dealloc the 
>>> superclass -dealloc calls -setObjectValue : nil which causes observation 
>>> warnings to be issued (I always try and clear these types of issues because 
>>> at the very least they mask real problems) as _objectValue will still be 
>>> non nil and [self removeObservers] gets called again.
>>> 
> 
>>> Is it normal for superclasses to message during dealloc?
> 
> I would still like to know what people’s expectations are here.

It is quite normal and done in a lot of places. 

FWIW, NSTableCellView’s dealloc looks like this:

- (void)dealloc {
    self.objectValue = nil;
    self.imageView = nil;
    self.textField = nil;
    [_aux release];
    [super dealloc];
}

All the properties are @synthesized.

corbin


> 
> Thanks
> 
> J
> 
> 
> _______________________________________________
> 
> Cocoa-dev mailing list ([email protected])
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/corbind%40apple.com
> 
> This email sent to [email protected]


_______________________________________________

Cocoa-dev mailing list ([email protected])

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to