Re: controllers, delegates, retain, release ...
Re: controllers, delegates, retain, release ...
- Subject: Re: controllers, delegates, retain, release ...
- From: Keith Duncan <email@hidden>
- Date: Fri, 22 Feb 2008 21:13:43 +0000
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@hidden)
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:
This email sent to email@hidden