FROM : Johnny Lundy
DATE : Thu May 22 23:13:20 2008
My point in using that class reference was simply to show how someone
could follow the "manual" and still have his code not work.
Actually, the "introductory documentation" never actually says that
the convenience constructors always return autoreleased objects -- it
just says that they "in general" do (paraphrasing).
Even more reason, IMO, for the Class Reference to explicitly say what
the class does with the returned objects.
The way it is written, the objects are retained; so one should
conclude that they are not autoreleased.
If that is true, there is nothing wrong with the documentation.
On May 22, 2008, at 4:45 PM, lists.apple.com wrote:
> Message: 13
> Date: Thu, 22 May 2008 16:15:22 -0400
> From: Andy Lee <<email_removed>>
> Subject: Re: Trying to understand -- please help...
> To: Cocoa-dev <<email_removed>>
> Message-ID: <<email_removed>>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> On May 22, 2008, at 11:43 AM, Greg Titus wrote:
>> On May 21, 2008, at 12:37 PM, Johnny Lundy wrote:
>>>
>>> This is just one example of that "little tidbit" that is always
>>> left out of these references by Apple. It seems to be the <.O. for
>>> some reason. The "tidbit" isn't some extraneous bell or whistle;
>>> it's always something fundamental.
>>>
>>> They can't take 2 lines instead of 1 to document the behavior of a
>>> class method?
>>
>> A lot of people have already mentioned that the memory management
>> semantics for these methods are the same everywhere and are
>> described in the conceptual documentation. I'd like to answer the
>> obvious follow up question: even if it is described in the concept
>> docs, how would it hurt to repeat it in the NSArray class method
>> references? It is just one more line...
>>
>> The reason is that the location of the information says something
>> very important about its specificity or generality.
> [...explanation snipped...]
>
> Silly me, I misread this post. Greg was answering why the line
> *shouldn't* be added, not arguing that it *should*.
>
> Anyway, I still think it wouldn't be so bad. Sometimes it's okay to
> denormalize data a little. I would only object if it were done
> inconsistently.
>
> --Andy
DATE : Thu May 22 23:13:20 2008
My point in using that class reference was simply to show how someone
could follow the "manual" and still have his code not work.
Actually, the "introductory documentation" never actually says that
the convenience constructors always return autoreleased objects -- it
just says that they "in general" do (paraphrasing).
Even more reason, IMO, for the Class Reference to explicitly say what
the class does with the returned objects.
The way it is written, the objects are retained; so one should
conclude that they are not autoreleased.
If that is true, there is nothing wrong with the documentation.
On May 22, 2008, at 4:45 PM, lists.apple.com wrote:
> Message: 13
> Date: Thu, 22 May 2008 16:15:22 -0400
> From: Andy Lee <<email_removed>>
> Subject: Re: Trying to understand -- please help...
> To: Cocoa-dev <<email_removed>>
> Message-ID: <<email_removed>>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> On May 22, 2008, at 11:43 AM, Greg Titus wrote:
>> On May 21, 2008, at 12:37 PM, Johnny Lundy wrote:
>>>
>>> This is just one example of that "little tidbit" that is always
>>> left out of these references by Apple. It seems to be the <.O. for
>>> some reason. The "tidbit" isn't some extraneous bell or whistle;
>>> it's always something fundamental.
>>>
>>> They can't take 2 lines instead of 1 to document the behavior of a
>>> class method?
>>
>> A lot of people have already mentioned that the memory management
>> semantics for these methods are the same everywhere and are
>> described in the conceptual documentation. I'd like to answer the
>> obvious follow up question: even if it is described in the concept
>> docs, how would it hurt to repeat it in the NSArray class method
>> references? It is just one more line...
>>
>> The reason is that the location of the information says something
>> very important about its specificity or generality.
> [...explanation snipped...]
>
> Silly me, I misread this post. Greg was answering why the line
> *shouldn't* be added, not arguing that it *should*.
>
> Anyway, I still think it wouldn't be so bad. Sometimes it's okay to
> denormalize data a little. I would only object if it were done
> inconsistently.
>
> --Andy






Cocoa mail archive

