On Fri, Feb 6, 2009 at 8:22 PM, Martin Wierschin <mar...@nisus.com> wrote: > The only requirement the method has is to return an object that is valid for > the caller. Because self is obviously valid, it's a perfectly legitimate > return value. The fact that the caller releases that string after making the > call is not any of the method's concern.
Yep. According to the Cocoa memory management guidelines, this, strictly speaking, is not guaranteed to be safe: id a = [foo someMethod]; [bar someOtherMethod]; [a someThirdMethod]; You *are* allowed to return objects where the only reference keeping it alive belongs to the object doing the returning. And you *are* allowed to destroy objects immediately in your methods. End conclusion: objects can go away in surprising places. This isn't to say that you should go sprinkle all of your code with retain/autorelease pairs. Often you can prove to your own satisfaction that foo and bar are unrelated, and acting on bar can't affect your object. But it can be easy to forget, and something like this really will kill your app: id a = [dictionary objectForKey:key]; [dictionary setObject:b forKey:key]; [a someMethod]; Be careful out there, boys and girls.... Mike _______________________________________________ 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
