Re: Should objects returned by indirection be autoreleased
Re: Should objects returned by indirection be autoreleased
- Subject: Re: Should objects returned by indirection be autoreleased
- From: Bill Bumgarner <email@hidden>
- Date: Fri, 12 May 2006 23:06:44 -0700
On May 12, 2006, at 10:32 PM, Lon Giese wrote:
you know Bill, you might be assuming that nscell will retain the
object... the docs do not say that... unless the docs specifically
promise to retain an object then dont count on it... it might or it
might not... thats the whole idea of encapsulation we dont care
what happens inside a class as long as its interface is well
defined. for instance the docs for NSArray explicitly says it
retains object added to it and releases those removed... so you can
depend on that... you can not depend on nscell retaining a
represented object... maybe it does and maybe it doesnt and maybe
apple might change whether it does or not... again thats the idea
of encapsulation and oop... It not really that big a deal because
it easy enough to retain an object you want to keep around...
It retains the object. I checked.
I wanted to make sure that the method was behaving as expected -- was
retaining the object-- as does the other set*: methods on NSCell.
If not, I was going to file a bug against the documentation to make
sure it quite clearly indicated that it wasn't retaining the object.
The whole retain/release/autorelease paradigm is very much about
providing a mechanism that preserves encapsulation.
It does this by allowing object A and object B to both have
references to object C without having to worry about who "owns" the
object. A and B can "own" references to the object and it matters
not which reference goes away first or last, C will be deallocated
when the last reference goes away.
In the case of NSCell, it is effectively owning a reference to the
represented object such that the developer can retrieve it later, at
whim. This is as the documentation states.
By the standards of Cocoa, this pattern requires retain/release.
It is the "at whim" part that is key. The cell has no idea when the
developer might retrieve the object or what might happen in between.
Therefore, the represented object must be retained or later retrieval
ain't gonna work.
Now, of course, if you grab a reference to the returned object and
start futzing with it while something else calls
setRepresentedObject: on the cell then, yeah, sure, your returned
object might get released out from under you. But if you are hanging
on to the reference long enough for that to happen, you should have
retained it in the process anyway. (And, of course, threads make
this harder -- but screwing with the AppKit from a thread isn't
generally the right thing to do anyway.... you got bigger problems if
it is a thread triggering the release while you are futzing with the
object from the MEL).
There are only a few cases where maintaining a reference does not
imply a retain. NSNotificationCenter's observers is one. There are
a handful of others. They are documented or should be -- if you
find a case where it isn't documented, file a bug.
Actually, I did file a bug against setRepresentedObject: to exactly
clarify the behavior.
b.bum
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden