Quincey –
In practice, the delegate is often -- independently of its role as
delegate -- the *owner* of the referencing object (e.g. a window
controller that is a delegate of a table view loaded from a nib file
is the owner of the nib file's contents, including, directly or
indirectly, the table view). However, in that case, there's no
reason why the owner would relinquish ownership of the owned object
during a delegate method.
Yes, those are the cases I was referring to.
Unless I'm missing something obvious.
Consider NSURLConnection’s -connectionDidFinishLoading: delegate method:
- (void)connectionDidFinishLoading:(NSURLConnection *)connection {
// Do stuff
[myReferenceToTheConnection release];
myReferenceToTheConnection = nil;
}
Now, in the case of NSURLConnection there’s no need to ensure the
connection object remains valid until the current autorelease pool
gets drained (aka at the end of the current run loop cycle). But one
doesn’t always know how a specific class is implemented, and in that
case autoreleasing can help you prevent malloc errors.
I admit these are probably edge cases, but I’ve stumpled upon them. So
while you may consider this overly cautious, writing such a macro
takes about ten seconds – time that is easily saved when using the
macro as it saves you one line of code each time you use it.
– Georg_______________________________________________
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 arch...@mail-archive.com
