Cocoa mail archive
Re: Trying to understand -- please help...
FROM : Ken Thomases
DATE : Wed May 21 23:28:54 2008
On May 21, 2008, at 1:35 PM, Johnny Lundy wrote:
> All it would take is a single sentence under the "Class Methods"
> header, to say that these methods autorelease the returned object
> (AND that such autoreleasing means that the object will be
> deallocated if the method in which it was created returns).
A big part of the reason that such a sentence isn't there is that it
isn't (always) accurate!
The contract of the convenience constructor only has two components:
1) it's not yours to release (unless you retain it, of course); and 2)
the lifetime lasts _at_least_ until the enclosing autorelease pool is
drained.
There's no promise that the object is autoreleased. There's no
promise that it will be deallocated if you neglect to retain it. It's
also just inaccurate that autoreleased objects "will be deallocated if
the method in which it was created returns". The current method can
return and the object won't be deallocated. It's only once you return
back to the framework that it _may_ be deallocated.
On the other hand, it might be a singleton (probable for something
like [NSArray array]). It might be owned by some other object and
have a lifetime longer than the autorelease pool. Etc.
Anything promised by the contract is just that -- a promise. It ties
Apple's hands regarding the way the framework may be implemented now
and for all time. So, it's in everybody's interest that the docs only
promise the minimum that is required for the framework to be useful,
leaving Apple substantial freedom to change the implementation behind
the scenes.
I continue to find it odd that anybody would expect to go straight to
the NSArray class reference, bypassing the introductory material about
basic memory management patterns used by the framework. Now, I can
readily imagine that people will read that material but not fully
absorb or grok it on the first (or second) pass through. We've all
been there. But if you later find yourself confused about memory
management, hopefully you at least remember that it was discussed in
one of the introductory documents and you'll go looking for it. (I'm
not saying that asking the list is wrong; it's not, but it's also not
a sign that the docs are lousy.)
Cheers,
Ken
DATE : Wed May 21 23:28:54 2008
On May 21, 2008, at 1:35 PM, Johnny Lundy wrote:
> All it would take is a single sentence under the "Class Methods"
> header, to say that these methods autorelease the returned object
> (AND that such autoreleasing means that the object will be
> deallocated if the method in which it was created returns).
A big part of the reason that such a sentence isn't there is that it
isn't (always) accurate!
The contract of the convenience constructor only has two components:
1) it's not yours to release (unless you retain it, of course); and 2)
the lifetime lasts _at_least_ until the enclosing autorelease pool is
drained.
There's no promise that the object is autoreleased. There's no
promise that it will be deallocated if you neglect to retain it. It's
also just inaccurate that autoreleased objects "will be deallocated if
the method in which it was created returns". The current method can
return and the object won't be deallocated. It's only once you return
back to the framework that it _may_ be deallocated.
On the other hand, it might be a singleton (probable for something
like [NSArray array]). It might be owned by some other object and
have a lifetime longer than the autorelease pool. Etc.
Anything promised by the contract is just that -- a promise. It ties
Apple's hands regarding the way the framework may be implemented now
and for all time. So, it's in everybody's interest that the docs only
promise the minimum that is required for the framework to be useful,
leaving Apple substantial freedom to change the implementation behind
the scenes.
I continue to find it odd that anybody would expect to go straight to
the NSArray class reference, bypassing the introductory material about
basic memory management patterns used by the framework. Now, I can
readily imagine that people will read that material but not fully
absorb or grok it on the first (or second) pass through. We've all
been there. But if you later find yourself confused about memory
management, hopefully you at least remember that it was discussed in
one of the introductory documents and you'll go looking for it. (I'm
not saying that asking the list is wrong; it's not, but it's also not
a sign that the docs are lousy.)
Cheers,
Ken
