On May 7, 2009, at 8:37 , Jeff Johnson wrote:
On May 7, 2009, at 2:38 AM, Marcel Weiher wrote:
EXACTLY. Autorelease allows ownership transfer from called
methods to occur without thrusting ownership on those that don't
want it.
That's one use, anyway.
No. That is what you need autorelease for. Anything else is fluff.
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.
where it otherwise may have been deallocated. The caller may only be
interested in analyzing the object to see its property or to compare
it to some other object without taking ownership of it.
Yes, and? If the object is still owned by the called object, then
there is no transfer of ownership and no need for autorelease. If the
called object relinquishes ownership, then and only then do you need
to autorelease, to allow it to get to the caller. Without
autorelease, the only way for the callee to give up ownership would be
straight release, and that would potentially deallocate the object
before it gets to the caller.
The delegate never has ownership of the object.
Usually the delegate is the owner. That is, the owner allocates
the object and sets itself as the delegate.
That's your opinion. Doesn't matter though: it is in the role of
the owner that the object gets to release the object, not in the
role of the delegate.
That's correct, which is why wrapping autorelease pools around your
delegate callbacks is a bad idea. :-)
Untrue. In fact, you probably should wrap autorelease pools around
your delegate callbacks, in order to clean up after your delegate.
And NSXMLParser is not a good example to generalize upon, because
as we see with your code fragment, you don't even need delegate
methods to know when it's done.
PRECISELY.
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.
Marcel
_______________________________________________
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
