On Sun, Jan 13, 2013, at 03:44 PM, Gordon Apple wrote: > It may be ancient but, IMHO, it should be fixed, at least for ARC. It > is a > major source of unnecessary retain cycles and the fix is simple. I went > ahead and created a simple wrapper for NSTimer, as I originally > described, > and it works perfectly. I am going to file an enhancement request.
ARC is a compile-time technology. NSTimer cannot change its runtime behavior based on the determination that you compiled your source code using ARC. And while you're more than entitled to file enhancement requests, it's quite unlikely that Apple is going to change the documented and historical behavior of such a fundamental class in foundational ways that have implications for object lifetimes and thread safety. > > You¹re right. I have a strong C++ background which does color my thinking > about how things should work. In my main window controllers, I use > ³wakeup² > calls to other controllers, rather then using ³awakeFromNib², because the > latter is unpredictable as to calling order. Maybe I should similarly > add > ³shutDown² calls so I can finalize and release contained controllers in a > prescribed order. I might even add a protocol with those two methods. Apple should do a better job of downplaying -awakeFromNib and encouraging use of -windowDidLoad and the like. -awakeFromNib is useful for instances that need to configure themselves in ways that IB doesn't support (particularly subclasses of framework objects that you know only ever live in a specific nib). But since you do have -windowDidLoad, why do you have an additional "wakeup" method? It seems like you're attempting to fix the pattern itself into code, rather than just specific implementations of it. In general, it sounds like you're tethering your subsystem interfaces too tightly to your objects' lifecycles. I am very familiar with this mental trap, and it is only really within the last year that I've gotten decent at recognizing and avoiding it. --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
