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: Lon Giese <email@hidden>
- Date: Sat, 13 May 2006 05:46:12 -0700
I am just trying to answer a newbie question and hope he isn't getting
too confused by this... most of what you are saying is correct but its
just confusing the question... we should keep it simple as possible to
answer the question put forth...
we pass around a lot of objects in cocoa and the main assumption is
that: IF some object wants to retain another object that he didn't
create or copy then that object must retain the desired object and not
depend that some other object will retain it for you... The notable
exception are the Set classes: NSArray, NSSet, NSDictionary, and to a
certain extent NSData... With these sets it is very convenient to
release a set and the set will release all the objects it contains:
another sort of delayed release mechanism. By releasing one NSArray
could start a reaction that releases tens of thousands of objects
neatly, smoothly and elegantly... deallocation code you would other
wise have to write...
The question was if he passes an object to NSCell will the object be
released when the NSCell deallocates... The answer is maybe - maybe
not.. the answer is inconsequential... You can be sure that
retain/realseses must be balanced. one retain-- one release... if the
NSCell retains the object passed to it you can be sure NSCell will also
release it at some point before the NSCell disapears from reality. An
object should never send a release simply because it thinks some one
else retained it and is not going to release it... thats stupid... All
Cocoa objects must be good citizens or the whole application comes
crashing down.
On May 12, 2006, at 11:06 PM, Bill Bumgarner wrote:
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