On May 6, 2009, at 7:57 PM, Marcel Weiher wrote:
On May 6, 2009, at 15:49 , Jeff Johnson wrote:
I still maintain that it's never safe to release/autorelease an
object
from inside one of it's delegate calls. If it works at all, you're
implicitly relying on an implementation detail that's subject to
change.
I find this idea somewhat suspect.
You shouldn't.
It seems to undermine the basic function of the autorelease call,
which is delay a release until later.
I think you misunderstand the problem that autorelease is trying to
solve, which is to allow ownership transfer from a callee back to
its caller, not to just simply delay a release until "later".
Ownership 'transfer' is rare. If you call +alloc or -copy, for
example, ownership is transferred to the caller. Otherwise, there's no
such thing. This is why you can't implement your getters as -
(id)myThing { return [_myThing retain]; }. When someone else calls -
myThing, you still own the object, which is why you're responsible for
balancing out the retain with an autorelease. You call release or
autorelease on an instance variable to relinquish ownership of the
object, not to 'transfer' ownership.
The reasoning here could be taken to the point of absurdity. This
is because a 'callee' (self, that is) never knows whether the
caller has wrapped the called method in an inner autorelease pool.
This is not absurdity, this is *precisely* the case.
I know it's the case, which is why I said it. The absurdity is that it
would never be safe to use autorelease. It may be true that there
could always be an autorelease pool around the call, but if the callee
has to worry about that, then what's the point of even using
autorelease at all? Might as well just always release objects, because
you have to assume that they're going to get released immediately
after the method returns, right?
Thus, the callee never knows whether its own calls to autorelease
will be subsequently turned into releases by the drained pool
immediately upon returning from the called method. Is the callee
never supposed to use autorelease, to be safe?
It should only use autorelease to give the caller the chance to
retain the object if it wants to, it cannot be used to "tunnel" the
object through the caller.
You indeed should be able to "tunnel" through the caller:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html#/
/apple_ref/doc/uid/20000043-1000580
"When another method gets the array of Sprocket objects, that method
can assume that the array will be disposed of when it is no longer
needed, but can still be safely used anywhere within its scope (see
“Validity of Shared Objects”). It can even return the array to its
invoker, since the application object defines the bottom of the call
stack for your code. The autorelease method thus allows every object
to use other objects without worrying about disposing of them."
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html#/
/apple_ref/doc/uid/20000043-1000922
"Cocoa’s ownership policy specifies that received objects should
remain valid throughout the scope of the calling method. It should
also be possible to return a received object from the current scope
without fear of it being released."
From the callee's perspective, a call to autorelease defers the
release until the end of the event loop.
That is completely wrong. Wherever you got that information from,
forget it, delete it, purge it, unremember it.
Heh, I can't very well delete Apple's documentation. "The autorelease
method, defined by NSObject, marks the receiver for later release."
If the caller does anything to shorten the lifetime of objects,
that's the callers own fault and responsibility.
No, it is the callers absolute right to do this.
Regards,
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
