Re: self release
Re: self release
- Subject: Re: self release
- From: David Remahl <email@hidden>
- Date: Mon, 12 May 2003 19:10:41 +0200
And even in that case, I usually think it feels safer to do an
autorelease instead. That way accessing an instance variable after the
release message wouldn't cause a lot of problems. Contrived example:
- (id)init
{
if( self = [super init] )
{
instanceVar1 = [NSString stringWithContentsOfFile:SOME_FILE];
if( !instanceVar1 ) // Perhas the file doesn't exist
{
[self release];
self = nil;
}
instanceVar2 = WHATEVER;
}
return self;
}
Granted, the above is bad coding practice (it would be better to do
return nil; after [self release], but there are cases where it isn't as
obvious.
Another time when it may be useful to send [self retain] and [self
autorelease/release] is when an object needs to continue to exist even
after the calling code has released it. Something like that must be at
work in NSURLHandle and relatives, which disappear once the transfer is
completed. It could be that some auxiliary object actually retains /
releases the URL handle, though. I've also used it for panels that are
partially autonomous and release themselves once they close. It could
also be handled at the controller level.
/ Rgds, David
On Monday, May 12, 2003, at 06:51 PM, John C. Randolph wrote:
On Monday, May 12, 2003, at 09:31 AM, Wolfgang Ante wrote:
Is it OK to "[self release]"?
The only time I've had occasion to do so was in an -init method, where
initialization failed and I needed to avoid leaking memory. Other
than such a situation, sending -release to self is very unusual.
-jcr
John C. Randolph <email@hidden> (408) 974-8819
Sr. Cocoa Software Engineer,
Apple Worldwide Developer Relations
http://developer.apple.com/cocoa/index.html
_______________________________________________
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.