NSPropertyListSerialization violates object ownership rules?
NSPropertyListSerialization violates object ownership rules?
- Subject: NSPropertyListSerialization violates object ownership rules?
- From: Jim Correia <email@hidden>
- Date: Sun, 6 Oct 2002 19:02:38 -0400
The documentation for NSPropertyListSerialization
dataFromPropertyList:format:errorDescription: says
dataFromPropertyList:format:errorDescription:
+ (NSData *)dataFromPropertyList:(id)plist
format:(NSPropertyListFormat)format errorDescription:(NSString
**)errorString
Returns an NSData object in the property list format specified by
plist or nil if plist does not represent a valid property list. plist
must be a kind of NSData, NSString, NSNumber, NSDate, NSArray, or
NSDictionary. Container objects must also contain only these kinds of
objects. On return, if the conversion is successful, errorString is
nil. If the conversion fails, errorString points to a string
describing the nature of the error. If you receive a string, you must
release it. Possible values for format are described in "Constants".
Is this correct? (That I must release the error string? That is the
current implementation seems to agree with the documentation, but seems
counter to the usual memory management rules.)
Isn't this counter to the usual Cocoa memory management "contract"
whereby if I didn't alloc, copy, or retain and object, I don't have to
release it? NSPropertyListSerialization is the one who created the
error string, but the documentation is passing the responsibility to me
to release it.
<file://localhost/Developer/Documentation/Cocoa/TasksAndConcepts/
ProgrammingTopics/MemoryMgmt/Concepts/ObjectOwnership.html#BEHDEDDB>
Ideally a body of code should never be concerned with releasing
something it did not create. Cocoa therefore sets this policy: If you
create an object (using alloc, allocWithZone:, or new) or copy an
object (using copy, copyWithZone:, mutableCopy,or
mutableCopyWithZone:), you alone are responsible for releasing it. If
you did not directly create or copy the object, you do not own it and
should not release it.
Which goes on to say:
When you write a method that creates and returns an object, either
directly or by reference in a parameter, that method is responsible
for releasing the object. However, it is clearly not fruitful to
dispose of an object before the recipient of the object gets it. What
is needed is a way to mark an object for release at a later time, so
that it will be properly disposed of after the recipient has had a
chance to use it. Cocoa provides just such a mechanism.
I raise the issue only because the previous state (and perhaps I was
confused) of only having to make sure I balance alloc, copy and retain
with release makes life lots simpler. When I call an API that returns
something (whether by return value or by reference in one of the
arguments) I know someone else is responsible for the memory. If this
in general is not going to be the case, I'll have to read the
documentation for all the methods and put my bean counter hat back on
like I do when using other frameworks.
Is this the only anomaly or are there others? (For instance +
[NSAppleScript compileAndReturnError:] returns a dictionary in the
param by reference, but doesn't mention anything about memory
management leading one to believe the usual convention of the object
being responsible applies.)
I'm happy to file a bug about the API in question if it is agreed by
the appropriate responsible parties that the API violates the object
ownership rules. (Though changing it after it shipped with one policy
does raise other issues.)
Jim
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.