Cocoa mail archive
Re: Understanding reference count ownership
FROM : mmalc Crawford
DATE : Thu May 08 16:55:57 2008
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."
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.
> 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.
> 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
DATE : Thu May 08 16:55:57 2008
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."
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.
> 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.
> 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
