Am Mo,18.08.2008 um 18:57 schrieb Michael Ash:
On Mon, Aug 18, 2008 at 11:51 AM, Negm-Awad Amin <[EMAIL PROTECTED]
> wrote:
But anyway I do not think, that doing something else then memory
management
in -dealloc is good design. Normally I unregister observation in
delegate
methods like -applicationWillTerminate:.
I think you may be a little too strict about this.
As I said, it is for teching. So Strictness (correct noun?) is a good
approach.
First, this really is memory management, it's just not so obvious.
You're removing another object's weak reference to your own object.
The logical place to do this is right before your own object is
deallocated.
Second, it's fine, even good, to clean up arbitrary resources in
-dealloc. There are two things to watch out for, though:
1) You shouldn't clean up *scarce* resources *only* in dealloc. For
example, file descriptors. It's fine to close fds in dealloc. In fact,
you really should do this. But you should *also* provide an explicit
"close" method and use it. The close in dealloc will just function as
a failsafe. This is because your object's lifetime may be much longer
than you want it to be due to things like autorelease pools, so you
want scarce resources to be under explicit control. This is much more
important in a GC environment than in the manual environment, however.
Yes, I saw, that observations of notifications can be understood as a
kind of memory management. But you can generalize this argumentation –
and then it becomes definetly wrong.
In this sense KVO is "a kind of memory management", too. Today I would
never deregister a KVO-observer in -dealloc as I did it some years ago.
2) You shouldn't clean up *external* resources *only* in dealloc. For
example, if you have an object that keeps a temporary file around,
then only deleting it in dealloc is a bad idea. This is because, as
you're probably aware, there's no guarantee that your objects get
deallocated before your application terminates. But again, it's fine
to do this kind of cleanup in dealloc as a failsafe, just don't have
it be the *only* place it happens.
What you don't want to do is make dealloc part of an RAII (Resources
Acquisition is Initialization) pattern,
Yes, that's it. In the past I handled – internal! – ressources very
often this way. I stopped doing so. GC was just the initial thinking:
"Hey, you are doing something in a method for memory managemt, which
has no relation to memory management."
As I said, I never have had problems with this approach in woking
code. But I do not like it anymore for design reasons.
or do long running
computations there,
No, there is no performance issue in my mind. It's simply design.
or things like that. But cleaning up external
references to your object before you disappear is a good thing to do
there.
I'll continue thinking about this …
Cheers,
Amin
Mike
_______________________________________________
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/negm-awad%40cocoading.de
This email sent to [EMAIL PROTECTED]
Amin Negm-Awad
[EMAIL PROTECTED]
_______________________________________________
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 [EMAIL PROTECTED]
