Cocoa mail archive
Re: Understanding reference count ownership
FROM : Sherm Pendley
DATE : Sat May 10 19:58:29 2008
On Sat, May 10, 2008 at 11:20 AM, Christiaan Hofman <<email_removed>>
wrote:
>
> On 8 May 2008, at 7:16 PM, Sherm Pendley wrote:
>
> On Thu, May 8, 2008 at 12:48 PM, Christiaan Hofman <<email_removed>>
> wrote:
>
>>
>> On 8 May 2008, at 6:28 PM, Sherm Pendley wrote:
>>
>> 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.
>>
>
> Spare me. This isn't politics, and you aren't Bill Clinton. You know
> perfectly well what create means, and you know perfectly well that sending a
> message to an existing object does not create the object.
>
> Apologies, but I have to respond to this.
>
> Seriously, I am not Bill Clinton, and I do *not* know what "create" means
> in this sentence. And I know perfectly well that sending a message to an
> existing object *can* create an object: -copy generally does, and I happen
> to know that this particular initializer *does* create a new object to
> replace the receiver (which is a temporary object). But those are
> implementation details, and implementation details should not matter.
> Personally, I'd say that +array creates a new object. However the docs say
> it doesn't.
>
They say no such thing. Again - you are far, far over-thinking this. The
memory-management docs we're referring to here list a few object creation
methods that imply a particular responsibility with respect to memory
management. The list is not an exhaustive list of every object creation
method, just a brief list of those few that bear the responsibility of a
matching release. Frankly, given the brevity of the list, the simplicity of
the rules, and the ease of creating compliant accesser methods (there are
even tools to automate it, like Accessorizer), I'm mystified as to why
*anyone* would have trouble with this. It's just not that hard!
The word "create" has nothing more than the ordinary, everyday English
meaning in Cocoa. All these docs are saying is, if you create an object by
any other means than the listed methods, you're not responsible for
releasing it. They're not trying to imply anything about the meaning of the
word "create," or whether this method or that fits the definition of the
word, etc.
When programming in Cocoa, I've found that common sense goes much farther
than nit-picking and hair-splitting.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
DATE : Sat May 10 19:58:29 2008
On Sat, May 10, 2008 at 11:20 AM, Christiaan Hofman <<email_removed>>
wrote:
>
> On 8 May 2008, at 7:16 PM, Sherm Pendley wrote:
>
> On Thu, May 8, 2008 at 12:48 PM, Christiaan Hofman <<email_removed>>
> wrote:
>
>>
>> On 8 May 2008, at 6:28 PM, Sherm Pendley wrote:
>>
>> 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.
>>
>
> Spare me. This isn't politics, and you aren't Bill Clinton. You know
> perfectly well what create means, and you know perfectly well that sending a
> message to an existing object does not create the object.
>
> Apologies, but I have to respond to this.
>
> Seriously, I am not Bill Clinton, and I do *not* know what "create" means
> in this sentence. And I know perfectly well that sending a message to an
> existing object *can* create an object: -copy generally does, and I happen
> to know that this particular initializer *does* create a new object to
> replace the receiver (which is a temporary object). But those are
> implementation details, and implementation details should not matter.
> Personally, I'd say that +array creates a new object. However the docs say
> it doesn't.
>
They say no such thing. Again - you are far, far over-thinking this. The
memory-management docs we're referring to here list a few object creation
methods that imply a particular responsibility with respect to memory
management. The list is not an exhaustive list of every object creation
method, just a brief list of those few that bear the responsibility of a
matching release. Frankly, given the brevity of the list, the simplicity of
the rules, and the ease of creating compliant accesser methods (there are
even tools to automate it, like Accessorizer), I'm mystified as to why
*anyone* would have trouble with this. It's just not that hard!
The word "create" has nothing more than the ordinary, everyday English
meaning in Cocoa. All these docs are saying is, if you create an object by
any other means than the listed methods, you're not responsible for
releasing it. They're not trying to imply anything about the meaning of the
word "create," or whether this method or that fits the definition of the
word, etc.
When programming in Cocoa, I've found that common sense goes much farther
than nit-picking and hair-splitting.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
