On 2011-06-29, at 19:17 , Kyle Sluder wrote:
Yes, it talks about certain*exceptions*, and you are right, one of them is in fact destroying the parent, so I'm wiling to accept that you must not rely upon an object to stay alive longer than its parent. However, have you also read the top paragraph?
"Cocoa’s ownership policy specifies that received objects should typically remain valid throughout the scope of the calling method. It should also be possible to return a received object from the current scope without fear of it being released. It should not matter to your application that the getter method of an object returns a cached instance variable or a computed value. What matters is that the object remains valid for the time you need it."
This principle is violated by a getter returning an object that is not retain+autorelease, since even without destroying the parent the returned object might go away. As pointed out in my other mail:
[someOtherObject setValue:[someObject value]];
value = ...;
if (value == aValue) return;
value = [aValue retain]; // <--- BANG, CRASH
It violates the policy stated above, even though this is *no collection* class and the parent has *not* been released. Neither of the two exception cases mentioned on the liked page above has been met!
If that was allowed, one would have to write code like this:
id value = [someObject value];
And nobody seriously writes such code.
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden