|
|
|
|
|
|
|
| PATH |

Suppose, for example, that you have a Thingamajig object that contains a number of Sprocket objects, which another object accesses with this method:
- (NSArray *) sprockets
This declaration says nothing about who should release the returned array. If the Thingamajig object returned an instance variable, it's responsible; if the Thingamajig created an array and returned it, the recipient is responsible. This problem applies both to objects returned by a method and objects passed in as arguments to a method.
Ideally a body of code should never be concerned with releasing something it didn't create. Cocoa therefore sets this policy:
If you create an object (using alloc or
allocWithZone:) or copy an object (using
copy, copyWithZone:,
mutableCopy, or mutableCopyWithZone:),
you alone are responsible for releasing it. |
If you didn't directly create or copy the object, you don't own it and shouldn't release it.
Note: It
is possible for you to create an object by invoking one of the +className... methods
of the class object. However, because these class methods allocate memory
for the object, they are considered to be the owners and are therefore responsible
for releasing the object. |
When you write a method that creates and returns an object, that method is responsible for releasing the object. However, it's 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.

© 2001 Apple Computer, Inc.
|
|
|
Contact Us | Privacy Notice Copyright © 2000 Apple Computer, Inc. All rights reserved. 1-800-MY-APPLE |