On Dec 26, 2008, at 10:18 AM, Robert Marini wrote:
Perhaps I wasn't clear enough in my statement as that was what I was
trying to get across - if it's only been retained once it will only
take one release message to trigger dealloc. As the author stated
in his first post, by retaining link, it works as expected which
would lead me to believe that link is the result of a convenience
method and is consequently autorelease.
Again, this is wrong-headed thinking.
A convenience method does *not* imply autorelease -- it simply says
that you don't own the returned object. Thinking in terms of object
ownership tends to lead to a much better understanding than discussing
in terms of retain/release/autorelease.
If that is the issue then yes, he *must* retain it if he expects it
to stick around.
And as Michael pointed out, in this case this is very unlikely to be
the issue, and as a pattern (modulo the issue that Joar pointed out,
and is discussed for example in "Second variant" here: <http://homepage.mac.com/mmalc/Stepwise/accessorMethods2.html
>).
Typically if you get an object you don't own you can expect it to
remain valid for the current scope (unless you're creating your own
autorelease pools, in which case you're expected to know what you're
doing...).
People new to the concepts of memory management tend to think of
balancing retain/release as just something you need to do at init
and dealloc which is, sometimes, quite correct. Autorelease makes
that slightly more complicated and so I've found this to be a solid
defensive practice for individuals who are starting out.
There should be no need for this.
The simple requirement is to understand the very basic rules of memory
management as described in <http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html
>. Adding "defensive programming" unnecessarily complicates the issue.
As I've said on a previous occasion, over the decade and a half, I've
come increasingly to the opinion that many of the problems that people
have with memory management are not with the Basic Rules -- if they
find and read them, then people can usually understand and apply them
readily enough -- but with incomplete, inaccurate, and misleading
explanations of memory management given by their peers...
If you are not retaining the object anywhere - explicitly claiming
responsibility for it's continued existence, it is not a severe bug
- it is behaving as expected. While a deeper understanding of
what's going on will naturally leader to code that is arguably
better in almost every way (<insert daft punk lyrics here>) you
cannot damage yourself by being too cautious with retain/release.
Yes, you can.
This simply leads to voodoo programming where retains and releases are
sprinkled throughout your code as a substitute for understanding. In
addition to deferring absorbtion of the Basic Rules, it's almost
certainly going to lead to a problem at some stage when you retain and
release rather than using accessor methods (see <http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html#//apple_ref/doc/uid/TP40004447-SW4
>).
mmalc
_______________________________________________
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
