On Aug 29, 2009, at 12:26, Andreas Grosam wrote:
Just to be clear, the code is running on the iPhone, hence there is no GC. Secondly, there is no issue with release or retain. If I invoke release from within a dealloc in order to release a certain object, I have to do it exactly the same way - even when the current KVO issue has been corrected somehow in my code. So, retain/release is unrelated to the current problem. The solution to my problem seems to be to unregister all KVO *before* the object hierarchy gets deallocated.
No, there's no issue with calling the 'release' and 'retain' methods. It's an issue of object lifetimes -- what and when. Incidentally, although GC isn't an iPhone issue now, I can't imagine that GC won't become available on the iPhone in the next couple of years. (Perhaps when CPU horsepower and battery life limitations have eased enough.)
If the dealloc method does not directly or indirectly invoke a method of any object that is currently deallocated, the design should be safe. But I wouldn't recommend it, because it may become a problem later when code changes.
Yours may be safe. Mine wasn't, the last time I wrote a non-GC app (which is nearly 2 years now). I managed to so overload the semantics of dealloc that I couldn't get my data model to go away. :)
Though, I don't see why this is a *second* problem - IMHO it's just a concrete reason of the one problem.
It really is just one problem, but I was trying to forestall comments like, "Well, things would be just fine if Apple didn't place this arbitrary restriction on unregistering." It's one problem, but it's larger than just unregistering.
Absolutely. Even when I have a mechanism to tear down an object hierarchy via a shutdown message, after shutdown has been received, the object is effectively invalid. If there exists a third object that holds a reference to this torn down object, problems may occur since the object became invalid prematurely.
I think you have two ways to approach this. One is ensure that your design correctly decides when an object is no longer needed, so that the question of messaging an "invalid" object never arises. The other is to put the object into a shutdown state, where messaging it is either harmless or returns an error or throws an exception.
How could this be implemented? When an object gets deallocated it always previously received release with retain count one or - in case of GC - the last reference diminished. When this happens, it is already to late for a notification.
This will probably make you laugh, or worse, but I think in the hardest cases the best solution will turn out to be ... reference counting (implemented manually). That is, if the criterion for when a shared object should free its resources is really as vague as "when no one wants the object any more", the object could track how many other objects have registered interest in it, using a pseudo-retain/pseudo- release messaging protocol.
Think of it this way. An object really has 2 lifetimes -- visibility and existence. GC (and other factors) take existence mostly outside your control (aside from housekeeping), but visibility is what you really care about.
_______________________________________________ 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]
