On Jan 14, 2013, at 2:38 PM, Kyle Sluder <k...@ksluder.com> wrote: > Given that Gordon's explicit use case involves one part of his app > setting up timers that point at objects in other parts of his app that > know nothing of the timers' existence, this sounds like a fragility > nightmare. > > The NSTimer ship has sailed.
I don't really see it. All you'd need would be a special initializer or convenience constructor, like +[NSMapTable strongToWeakObjectsMapTable]. Make versions of the +timerWithTimeInterval:etc:etc: classes which would cause the created NSTimer to weakly retain its target, and it'd just work. Adding something blocks-based instead of the target/selector stuff would of course be great too. Of course, Quincey makes a great point that with GCD timers, we don't really need NSTimer anymore, and that it might simply be deemed to have outlived its purpose. Then again, this — On Jan 14, 2013, at 3:25 PM, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote: > Of course, it may just be a signal that Apple hasn't gotten to > blocks-enhancing NSTimer yet is probably just as likely a possibility, given the other areas in Cocoa where blocks seem like the most natural solution in the world, but where Apple still sticks to target/selector only for whatever reason (NSApplication's sheet support, I'm looking at you). Charles _______________________________________________ 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
