On Wed, Jul 8, 2009 at 7:28 PM, Jeff Laing<jeff.la...@spatialinfo.com> 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 (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
