On May 7, 2009, at 11:18 AM, Marcel Weiher wrote:
On May 7, 2009, at 8:37 , Jeff Johnson wrote:
No, autorelease can be used to ensure that the returned object is
valid within the scope of the caller,
You can *try* to use it to ensure that, but as we have found out,
you have no way of actually succeeding without controlling the
caller. Autorelease has no way of actually ensuring that:
id pool=[NSAutoreleasePool new];
id anObject=[callee getMeSomeObject];
[pool release];
[anObject foo];
Again, the documentation is a bit sloppy here, though understandably
so. I certainly don't know of anyone else who misread what is
written there as a guarantee for the callee, when it is obviously at
most a (qualified) guarantee for the caller.
You misunderstand my argument. I'm not claiming that autorelease
provides some magical guarantee. I'm claiming that you ought to write
your code to provide the guarantee. So, for example, don't wrap
delegate callbacks in autorelease pools. There's no need to 'clean up'
after your delegate, as you say. This is a not only a misapplication
of memory management responsibility, but it can lead to unintended and
very bad side effects.
Furthermore, I think you can count on Apple to not do anything like
that (and if they do, it's a bug they ought to fix). Why do you think
they suggest creating an autorelease pool inside your NSXMLParser
callback rather than just doing it themselves automatically? Because
automatically shortening the lifespan of objects in the delegate is
unwise and can lead to bad side effects. Note also that Apple's
methods return objects that remain valid. You can do NSString
*oldTitle= [window title]; [window setTitle:@"New title"]; [oldTitle
doSomething]; without fear of crashing. Any exceptions are documented,
such as -[NSArray objectAtIndex:].
I'm still waiting to hear a solution for the fully async cases.
What "fully async" case? Message-sending in Objective-C is
synchronous.
Now you're just being obtuse, because I already mentioned
NSURLConnection, for example. Is the connection finished loading
when -[NSURLConnection initWithRequest:delegate:] returns? Unless
there was an immediate error, no.
Your point being? What does the initializer have to do with
anything? The way I have handled NSURLConnection's
didFinishLoading: method has been to set a flag that is then
evaluated at some other time. If you wanted to handle it via
messaging and actually ensure the thing you were incorrectly
assuming with autorelease, namely that the action is taken after the
current runloop cycle finishes, you can use the -perform:withDelay:
class of methods.
Heh, "at some other time". That's very vague. How do you guarantee
that everything is finished before you release the object? And no, by
your line of reasoning, you can't use
performSelector:withObject:afterDelay:, because the caller could not
only wrap the callback in an autorelease pool but also manually run
the run loop after the callback returns! ;-)
_______________________________________________
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
