On Wed, May 6, 2009 at 5:49 PM, Jeff Johnson <publicpost...@lapcatsoftware.com> wrote: > I find this idea somewhat suspect. It seems to undermine the basic function > of the autorelease call, which is 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. 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? > > From the callee's perspective, a call to autorelease defers the release > until the end of the event loop. If the caller does anything to shorten the > lifetime of objects, that's the callers own fault and responsibility. > > In my opinion, the above code is very questionable. You're just asking for > trouble if you create an autorelease pool yourself and then call out to the > unknown, especially to an object for which you only have a weak reference > and who is probably your owner, the delegate. You are purposely shortening > the lifetime of objects, so you're responsible for making sure nothing > important gets deallocated prematurely.
Listen: autorelease in its simplest form means "release this object sometime after the current method returns." No guarantees are made beyond that. It could be released earlier if you're managing your own autorelease pools. If you think the Apple docs guarantee anything else, then you need to go back and carefully re-read them. Now, with that in mind, take a look at the example I gave. For autorelease to work how you want it to, you need it to delay release AT LEAST TWO method returns. The return from the delegate callback, and the return from whatever called that method. There is absolutely nothing in the autorelease contact that says it will defer release this long. Which is why autorelease, in this example, is a very bad idea. _______________________________________________ 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
