Re: Clarification on accessors? (was: Yet another memory management question)
Re: Clarification on accessors? (was: Yet another memory management question)
- Subject: Re: Clarification on accessors? (was: Yet another memory management question)
- From: Kyle Sluder <email@hidden>
- Date: Wed, 8 Jul 2009 19:40:20 -0700
On Wed, Jul 8, 2009 at 7:28 PM, Jeff Laing<email@hidden> wrote:
>> Because you have no idea what subclassers may do in their overrides of
>> the accessors
>
> Sort of invalidates the whole encapsulation promise of OO design, doesn't it?
No, it doesn't. It would in fact violate the encapsulation principle
if your -dealloc method required your accessors to not rely on certain
state.
>> (e.g. The subclassed accessor may rely on state that's
>> been torn down earlier in -dealloc).
>
> But any subclass that's going to override an accessor has had its dealloc method called already, so it should know to have put back anything that matters. Now, if you want to design based on the assumption that everyone else will do a crappy job, that's a different story.
So you're essentially saying everyone's derived accessors must check
if -dealloc has been called and avoid doing anything that might
interfere with super's implementation of -dealloc. That doesn't seem
tenable.
>> It's just not safe, unless you can guarantee that you own the entire
>> inheritance chain.
>
> Someone more knowledgeable than me should bring up the discussion about using the need to use the 'view' set-accessor in dealloc of subclassed view controllers, I think it was.
Don't see what the issue is here. As long as -[NSViewController
dealloc] doesn't rely on -view -- and it's this independence that
we're discussing here -- then you can use it just fine (as long as you
do it before calling super's implementation of -dealloc, otherwise all
bets are off).
--Kyle Sluder
_______________________________________________
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