Re: A legitimate argument for calling dealloc directly?
Re: A legitimate argument for calling dealloc directly?
- Subject: Re: A legitimate argument for calling dealloc directly?
- From: Dietrich Epp <email@hidden>
- Date: Mon, 13 Jan 2003 18:10:01 -0800
On Monday, January 13, 2003, at 04:52 , Daniel Jalkut wrote:
I am implementing a class of object that needs to periodically
"reinitialize" itself (in response to changed files on disk). This
class inherits from a class that is out of my direct control, so as far
as I can tell the only "safe" way to make sure that both the super
class and my own instance variables are "reset" is to manually call
[self dealloc] and then [self init].
I know calling dealloc instead of release is discouraged, but in this
case I don't want to release and reallocate (the object is being
managed in a data structure, and I'd like the data structure to keep
the same "handle" on it).
Is this totally skanky? Is there something dangerous I'm overlooking
here? Is there a better way to "reinvent" an object at the same
address of the old one? I could, instead of subclassing the super,
just keep an instance variable for it, but then I'd lose the
convenience of calling super's methods directly on my class.
Dealloc does exactly what it says. It deallocates the object, poof!
It's gone. I think the problem is less that it is difficult (and
dangerous) to reinitialize an object that is still being referenced, the
problem is more that this particular method of reloading data shows poor
design. If you could be more specific, you would get more specific help.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.