> 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.
The "ability to override accessors violates encapsulation" because it adds additional restrictions to the accessor that the superclass is not aware of. If you can't write your override of an accessor in such a way that you don't place additional restrictions on the superclass, you shouldn't do it. Because its not possible for you to make the assumption that "the superclass will never care" - without making (unjustifiable) assumptions about the superclasses implementation. My response was to someone presumably writing about Design Patterns, I believe who wanted to know what was the best approach to take. My opinion is that you should *not* assume that subclassers are idiots, because it doesn't matter how much bullet-proofing you put in, there's always going to be a worse idiot come along. Better to make them all have to work carefully, than to avoid using things *they* might screw up. > 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. Not everyones - only the ones that know they depend on some complicated local state that they might have screwed up. You can assume that the superclasses state is just fine because he hasn't been dealloc'd yet. > > 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). As I said, someone more knowledgeable than I needs to respond but as I recall, the issue went that the view controller superclass implemented some sort of additional cleanup that only occurred if you used the accessor to set view to nil. If you just set the instance variable to nil, it would leak. _______________________________________________ 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
