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 (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
