Re: dealloc query for NSTableCellView
Re: dealloc query for NSTableCellView
- Subject: Re: dealloc query for NSTableCellView
- From: Corbin Dunn <email@hidden>
- Date: Thu, 05 Feb 2015 08:31:01 -0800
> On Feb 4, 2015, at 5:43 AM, Jonathan Mitchell <email@hidden> wrote:
>
>
>> On 4 Feb 2015, at 13:27, Roland King <email@hidden> 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@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden