On May 21, 2008, at 1:35 PM, Johnny Lundy wrote:
All it would take is a single sentence under the "Class Methods" header, to say that these methods autorelease the returned object (AND that such autoreleasing means that the object will be deallocated if the method in which it was created returns).
A big part of the reason that such a sentence isn't there is that it isn't (always) accurate!
The contract of the convenience constructor only has two components: 1) it's not yours to release (unless you retain it, of course); and 2) the lifetime lasts _at_least_ until the enclosing autorelease pool is drained.
There's no promise that the object is autoreleased. There's no promise that it will be deallocated if you neglect to retain it. It's also just inaccurate that autoreleased objects "will be deallocated if the method in which it was created returns". The current method can return and the object won't be deallocated. It's only once you return back to the framework that it _may_ be deallocated.
On the other hand, it might be a singleton (probable for something like [NSArray array]). It might be owned by some other object and have a lifetime longer than the autorelease pool. Etc.
Anything promised by the contract is just that -- a promise. It ties Apple's hands regarding the way the framework may be implemented now and for all time. So, it's in everybody's interest that the docs only promise the minimum that is required for the framework to be useful, leaving Apple substantial freedom to change the implementation behind the scenes.
I continue to find it odd that anybody would expect to go straight to the NSArray class reference, bypassing the introductory material about basic memory management patterns used by the framework. Now, I can readily imagine that people will read that material but not fully absorb or grok it on the first (or second) pass through. We've all been there. But if you later find yourself confused about memory management, hopefully you at least remember that it was discussed in one of the introductory documents and you'll go looking for it. (I'm not saying that asking the list is wrong; it's not, but it's also not a sign that the docs are lousy.)
Cheers, Ken _______________________________________________ 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 [EMAIL PROTECTED]
