For the Good of the List
For the Good of the List
- Subject: For the Good of the List
- From: Lon Giese <email@hidden>
- Date: Sun, 14 May 2006 17:51:26 -0700
What I am saying IS correct, (It is not proper OOP style to depend on
what another class does internally, unless the PUBLIC interface
promises certain internal behavior), although some some may not be
reading what I am saying correctly, or I may not be saying it the same
way you would say it, or I am not saying what you are saying. The
english language is incredibly rich, so its easy to quibble over
semantics.
However, since everything I write seems to get an argument, I will stop
replying to any posts... I do this for the good of the list, not
because of any bad feelings... I don't want to cause a disruption or
decrease the signal to noise... If I have offended anyone I apologize.
I was simply trying to contribute and it seems that my contributions
are hurting rather than helping.
I commend the usefulness of this mailing list and hope no one has any
hard feelings towards me, that no one minds if I continue to subscribe
and maybe post an occasional question of my own.
BTW: If anyone here is a SIMS 2 Fan, You can download my latest Sims 2
Tool for OS X at http://www.modthesims2.com/showthread.php?t=157204
(Please, do not comment on it here)
Lon
On May 13, 2006, at 10:00 AM, Bill Bumgarner wrote:
I had already started this when Mmalc EOT'd the thread. He can
decide if this warrants posting to the list.
On May 13, 2006, at 5:46 AM, Lon Giese wrote: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...
Answering a question incorrectly in simple terms isn't helping.
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...
That is incorrect.
It is universally true that if you pass an object to a set method and
can retrieve said object via a get method, then the instance
containing the object must have retained it.
If the object decides to not hang on to the object passed to it, it
might release it but a later call to the get method better return nil
(or some other object).
If you needed the particular instance of the object you passed to the
set method in the first place, you should have stored a retained
reference somewhere.
However, saying that you cannot rely on other objects to retain
objects passed to them is incorrect.
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.
The answer is neither inconsequential or unspecified. Cocoa memory
management semantics guarantee that the cell will retain the
represented object unless documented otherwise.
In the case of the original question, the issue is whether or not the
developer needed to "own" a reference to the represented object. If
the developer was using the instance passed to setRepresentedObject:
purely in the role of a Cell's represented object, then the object's
lifespan will be appropriately managed by the Cell. If the developer
is expecting to use the object in a role beyond that, then stashing
away a retained reference is required.
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