> On 4 Feb 2015, at 21:16, Jonathan Mitchell <jonat...@mugginsoft.com> wrote:
>
> In my arc app I dispose of observers in -dealloc.
> The pattern I have established seems to work well but one case has me
> rethinking my approach.
> Everything pivots around NSViewController -representedObject;
>
> - (void)setRepresentedObject:(id)object
> {
> if (self.representedObject) [self removeObservers];
> [super setRepresentedObject:object];
> if (self.representedObject) [self addObservers];
> }
>
> - (void)dealloc
> {
> if (self.representedObject) [self removeObservers];
> }
>
> In my query case I have subclassed NSTableCellView. The principle is the
> same, but the signatures now are:
>
> - (void)setObjectValue:(id)object
> {
> if (self.objectValue) [self removeObservers];
> [super setObjectValue:object];
> if (self.objectValue) [self addObservers];
> }
>
> - (void)dealloc
> {
> if (self.objectValue) [self removeObservers];
> }
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.
>
> 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 could be triggering any sequence of non dealloc friendly actions as a
> result of the call to -setObjectValue:.
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
>
> This email sent to r...@rols.org
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
