FWIW, I wouldn't call it wrong for an object to manage its own lifetime. You'll leak UIs if the notification never appears, but this is apparently not a problem.
This would be a problem should the code base ever be compiled with GC support. Granted that is unlikely as this is an existing code base using retain/release logic but I feel that compiling with GC enabled helps to expose poor design decisions, i.e. well designed code should be able to be compiled GC supported without any changes. I'm not one of the lucky few who can claim to have a perfectly designed code base, even my unreleased Leopard transitioned app required some changes.
Back on topic I would agree with the OP, this way of doing things it Not Good.
I'm a purist, so I feel that the net retain count in any block should be zero (there are exceptions to every rule, I guess I'm not that much of a purist!). I'd solve this by placing the UI object in a mutable set when creating it. I'd then release it - remove it from the set - in a delegate callback. This is a much more sustainable and future proof pattern, should the controller need to do any work when the UI object returns, it can.
Keith _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [EMAIL PROTECTED]
