Skip navigation.
 
mlRe: Understanding reference count ownership
FROM : Christiaan Hofman
DATE : Thu May 08 18:48:16 2008

On 8 May 2008, at 6:28 PM, Sherm Pendley wrote:

> On Thu, May 8, 2008 at 12:09 PM, Christiaan Hofman 
> <<email_removed>> wrote:
>
> On 8 May 2008, at 5:50 PM, Sherm Pendley wrote:

>> On Thu, May 8, 2008 at 11:16 AM, Christiaan Hofman <<email_removed>
>> > wrote:
>>
>> E.g. initWithObjects:copyItems:. I couldn't find it in the 
>> ownership management docs, nor in the description of the method 
>> itself.
>>
>> There's no special mention in the method docs, because none is 
>> needed - the general rules apply to this method as-is.

> The sentence I linked to and mmalc quoted clearly says 'contains 
> "copy"', and this method name obviously contains the word "copy".
>
> The linked-to sentence says "if you create it using a method whose 
> name begins with "alloc" or "new" or contains "copy"". You created 
> the array object with +alloc, and then sent it an -
> initWithObjects:copyItems.
>


That depends on what "create" means. In the docs this is defined 
circular. This is how it is defined in the docs (Object Ownership 
Policy):

You "create" an object using a method whose name begins with “alloc” 
or “new” or contains “copy” (for example, alloc, newObject, or 
mutableCopy).

> Notice that I'm using the word "might"; what I'm saying here is that 
> the description is not as clear as it could be.
>
> It's crystal clear.


No, it's not.

> You're not creating an object; you did that with +alloc. What you're 
> doing with -initWithObjects:copyItems is sending a message to an 
> existing object. So whether that message has "copy" in its name is 
> completely irrelevant to memory management.
>


In fact a new instance *is* created in this particular example, to 
replace the temporary receiver (though not by you, but internally by 
the class). So there is a reason for an argument.

It would have been crystal clear if "class method" was used in both 
sentences, instead of just "method". Then the definition of "create" 
would have been unambiguous. Now it's not.

> But the main point is what I said above, which would imply that the 
> created array has an extra implicit retain
>
> The -initWithObjects:copyItems: method doesn't create a new object, 
> so the presence of "copy" in its name implies no such thing.
>
> sherm--


Can't find that part of the definition in the docs.

Anyway, this discussion is turning too philosophical, it's better to 
terminate, because we all know exactly what is meant.

Christiaan

Related mailsAuthorDate
mlUnderstanding reference count ownership Gregory Seidman May 7, 23:32
mlRe: Understanding reference count ownership Christiaan Hofman May 7, 23:47
mlRe: Understanding reference count ownership j o a r May 7, 23:47
mlRe: Understanding reference count ownership Jim Correia May 7, 23:49
mlRe: Understanding reference count ownership mmalc Crawford May 8, 01:34
mlRe: Understanding reference count ownership Paul Sargent May 8, 15:16
mlRe: Understanding reference count ownership Christiaan Hofman May 8, 15:32
mlRe: Understanding reference count ownership mmalc Crawford May 8, 16:55
mlRe: Understanding reference count ownership Christiaan Hofman May 8, 17:16
mlRe: Understanding reference count ownership j o a r May 8, 17:30
mlRe: Understanding reference count ownership Sherm Pendley May 8, 17:50
mlRe: Understanding reference count ownership Christiaan Hofman May 8, 18:09
mlRe: Understanding reference count ownership Sherm Pendley May 8, 18:28
mlRe: Understanding reference count ownership Christiaan Hofman May 8, 18:48
mlRe: Understanding reference count ownership Sherm Pendley May 8, 19:16
mlRe: Understanding reference count ownership Christiaan Hofman May 10, 17:20
mlRe: Understanding reference count ownership Sherm Pendley May 10, 19:58
mlRe: Understanding reference count ownership Clark Cox May 10, 20:36