Recursive run loops always lead to cleaner but worse code (IMO, of course :)). Recursive mouse tracking, for example, keeps all the code dealing with the state changes in one place, and allows for method-scope variables that keep track of the state rather than ivars. On the other hand, you have to explicitly schedule timers and delayed actions to perform on the mouse-tracking run loop mode, or else they'll be delayed until the user mouses-up. I can never seem to remember to do this, and it always leads to a that d'oh! moment.
Worse, I've found the frameworks make use of recursive run loops where you'd least expect it, and I've never seen it documented in these cases. This bit me in the case of NSTask's -isRunning. (And not only does -isRunning run the run loop, but you can receive the NSTaskDidTerminateNotification from within -isRunning's stack frame - ouch. Guess I should file a bug about that, instead of just complaining, eh? :)) I've hit several other brick walls from recursive run loops, but they escape me at the moment. Nonetheless, recursive run loops are a fancy way of blocking, and are contrary to the event-driven model that we know and love. I guess the rule that I stick by is "Don't use recursive run loops. But If you do, never (ever!) run them in anything but a custom run loop mode." _______________________________________________ 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
