Re: Understanding reference count ownership

FROM : Christiaan Hofman
DATE : Thu May 08 17:16:25 2008

On 8 May 2008, at 4:55 PM, mmalc Crawford wrote:

>
> On May 8, 2008, at 6:16 AM, Paul Sargent wrote:
>

>>>> No. The rule is that only methods containing "create", "copy", 
>>>> and "alloc" in their name implicitly retain.

>>>
>>> No, this is wrong.

>>
>> I have to say, even with a link to the documentation, that 
>> statement just makes me more confused. I'm not sure what it is 
>> you're objecting to.
>>

> Even a cursory glance at the documentation should reveal that the 
> "rule" given in the original message is not the same as that given 
> in the documentation:
>
> "You take ownership of an object if you create it using a method 
> whose name begins with “alloc” or “new” or contains “copy” (for 
> example, alloc, newObject, or mutableCopy), or if you send it a 
> retain message."
>


Sure, but that's not what I'm saying. I don't disagree that I was 
wrong and too quick to answer. I'm just explaining what led me to this 
confusion. Also this very sentence is a case in point: here and at 
several p[laces in these docs the word "create" is used to describe 
making an object that you own. So it's at least counter-intuitive to 
use the word "new" to indicate it in a method name.

>
>
> On May 8, 2008, at 6:32 AM, Christiaan Hofman wrote:

>> I know, because I know what gets me confused. It's not "create" but 
>> "new". The confusion is partly due to the OP (who listed it as the 
>> part he said he understands), and partly due to Carbon, as there 
>> the similar keywords are "Copy" and "Create".
>>

> And (used as a modifier to your original post) that's still wrong -- 
> see above.
>


It's the main point. And the part about begins and contains is at 
least partly wrong (-initWithArray:copyItems: would implicitly retain 
according to this sentence). And "retain" should be just obvious to 
anyone. This is just nitpicking. And again I was just explaining the 
source of confusion.

>

>> IMHO, I think the "new" rule was a mistake, because it's confusing 
>> (given the Carbon rule), and moreover it is rather an exception 
>> than a rule (I've never used it, and I know only a single example 
>> in Cocoa, which is an utterly expendable).
>>

> The "new" rule considerably predates Carbon.  There are several 
> examples, as a trivial search in Xcode for example will reveal.
> Moreover, it allows for a useful general pattern.  If you want to 
> specify a "convenience constructor" that returns an object that the 
> caller owns, then you can prepend "new" to the method name.  This 
> has particular value if you want to avoid autorelease.
>


I know. I'm just saying that in hindsight, I truly believe that 
"create" would have been far more appropriate and intuitive, and 
moreover, more consistent, because of the Carbon rule as it is also a 
verb, like allocate, copy, retain. Again,. I'm explaining my source of 
confusion.

>

>> Also note that the documentation <http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html

>> > is not sacred, as it has exceptions (which are not mentioned in 
>> the ownership docs AFAICS).
>>

> As a fundamental set of rules, they are "sacred".  Such rare 
> exceptions as there are are called out in the documentation where 
> appropriate.
>
> mmalc
>


E.g. initWithObjects:copyItems:. I couldn't find it in the ownership 
management docs, nor in the description of the method itself. In fact, 
that description might make you believe that the objects from the 
array are copied, and therefore should be released by you!

Christiaan