On Jan 12, 2013, at 12:16 PM, Gordon Apple <g...@ed4u.com> wrote: > And just how does one go about doing that? The only way I can see is to use > an owner’s dealloc to call something like “wouldLikeToDealloc” on the owned > object.
Retain/release is just an implementation of a pattern. You can implement it yourself, or use one of the other existing implementations the framework provides for you: -viewDidMoveToSuperview, -windowWillClose, etc. > From the literature, it appears that NSTimer is the main offender in this > regard. NSTimer is something like twenty years old, but it is also decently documented. The run loop maintains a strong reference to the timer. The timer maintains a strong reference to its target. The chain is broken when the timer is invalidated. > I frequently use generic NSViewControllers and NSWindowControllers which have > no link to the controller containing the timer. The good thing about writing application code, rather than framework code, is that you can fix this problem and your solution can be both specific and correct. Meanwhile, you have no guarantee that some random piece of framework code hasn't retained your window controller or view controller, and now all of a sudden the timer you installed elsewhere is still firing at your view controllers but the model objects have been deallocated… This isn't C++. RAII is not a valid pattern in Cocoa. Do not use object lifecycle to manage interactions between app components. Instead, make the targets of your timers aware enough of their use that they can signal for the timer to be invalidated at the appropriate time. --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
