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".
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.
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.
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.
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
