2. [somewhat important] It instills a false sense of security, but implying that extending the object lifetime to the next pool drain is always a sufficient lifetime extension. It isn't, not necessarily.
Yes, I think that’s the point the we’ve been paying most attention to.
3. [somewhat more important] If you switch to garbage collection, solving the original problem (in the NSURLConnection case) with autorelease isn't possible. Under GC, the "defect" (if you'll excuse the word) in your original design is revealed, and finding a solution may be considerably more difficult.
That’s a very good point! So for code that should run in both reference-counting and memory-managed environments this actually is a strong point *against* autoreleasing, because it wouldn’t expose bugs (in the delegating class) in the memory-managed image that would surface in the reference-counting one.
– Georg _______________________________________________ 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
