Re: Properties, Attributes and Retain+Autorelease
Re: Properties, Attributes and Retain+Autorelease
- Subject: Re: Properties, Attributes and Retain+Autorelease
- From: Eeyore <email@hidden>
- Date: Wed, 29 Jun 2011 11:26:00 -0700
Still learning Cocoa myself, so hoping to be corrected if I'm wrong.
On Jun 29, 2011, at 10:39 AM, Markus Hanauska wrote:
> "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:
>
I guess I'm not sure what the debate is. Are you questioning whether Apple's code honors the agreement? If you find an instance where Apple's code is actually violating this agreement, then you should file a bug. Otherwise, you should probably work under the assumption that all of Apple's getters other than those specifically excluded will retain/autorelease and that synthesized getters will also follow a retain/autorelease pattern.
> // someObject
>
> - (id)value
> {
> return value;
> }
>
> - (void)doSomething
> {
> // ...
> [value release];
> value = ...;
> / /...
> }
> // someOtherObject
>
> - (void)setValue:(id)aValue
> {
> [someObject doSomething];
> if (value == aValue) return;
>
> [value release];
> value = [aValue retain]; // <--- BANG, CRASH
> }
On the other hand, if you are writing your own getters and setters, of course you can break the contract (as someObject does here). Matt Gallagher writes about this in http://cocoawithlove.com/2010/06/assign-retain-copy-pitfalls-in-obj-c.html where he says that he typically does not follow a retain/autorelease but is aware that the result would be more correct with them. If you get the BANG-CRASH and are the author of someOtherObject, you should submit a bug to someObject's author and then put a workaround in place, two possible examples:
> [someOtherObject setValue: [[[someObject value] retain] autorelease]]; // retain/autorelease required due to bug in [someObject value]
or possibly, use a category to extend someObject to provide a safe getter as a work-around
> - (id)safeValue
> {
> return [[[self value] retain] autorelease];
> }
and then never use value, but use safeValue instead
> [someOtherObject setValue: [someObject safeValue]];
Both workarounds would be removed when the author of someObject gets his/her act together (either by retain/autoreleasing in the getter or by autoreleasing in doSomething).
Aaron
_______________________________________________
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