Cocoa mail archive
Re: Intercepting retain/release of object
FROM : Jack Repenning
DATE : Mon Mar 24 17:12:15 2008
On Mar 23, 2008, at 9:50 PM, Stuart Malin wrote:
> For neary all of my code, I have nice, straightforward retain-
> release pathways. The one that had been giving me trouble is an
> oddball: I have a factory class that generates an instance. That
> instance is bounced around handlers of a state machine.
All the time I was writing that "do it in the accessors" stuff, I was
feeling guilty, because I have one case, quite like yours, where I've
had to do something quite notably non-obvious. So I'm eager to hear
if anyone has a better solution.
What I've done is to make this object responsible for its own life
cycle. Its users create it with a "whateverWithStuff" sort of
routine, not an alloc or similar (that is, they do not acquire any
responsibility for release merely by having a ref to the object; if
they hang on to it somehow, then their in-the-accessors retain/release
mechanisms still apply). Inside my whateverWithStuff constructor, I
retain the object, or allow the implicit retain of the underlying
alloc to remain in place, actually. Now, my state machines and
threads can toss the object about freely, retaining when they hold it,
releasing when they're done, letting their call-stacks fall down
through autorelease pools and back to the user input looop, and never
worrying about the object disappearing prematurely. At the end, the
object itself actually knows (in my case) that it's all used up
(because of its windowWillClose), and that routine autoreleases the
object, eventually discharging the long-standing release obligation
left open back in whateverWithStuff.
This stretches the "at-a-glance" retain/release verifiability a bit,
but at least the retains and releases are balanced within the class.
Some objects explicitly provide a "close" method, or something of the
sort, something that their users are responsible to call when they're
done with the object, and the final autorelease goes there.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
DATE : Mon Mar 24 17:12:15 2008
On Mar 23, 2008, at 9:50 PM, Stuart Malin wrote:
> For neary all of my code, I have nice, straightforward retain-
> release pathways. The one that had been giving me trouble is an
> oddball: I have a factory class that generates an instance. That
> instance is bounced around handlers of a state machine.
All the time I was writing that "do it in the accessors" stuff, I was
feeling guilty, because I have one case, quite like yours, where I've
had to do something quite notably non-obvious. So I'm eager to hear
if anyone has a better solution.
What I've done is to make this object responsible for its own life
cycle. Its users create it with a "whateverWithStuff" sort of
routine, not an alloc or similar (that is, they do not acquire any
responsibility for release merely by having a ref to the object; if
they hang on to it somehow, then their in-the-accessors retain/release
mechanisms still apply). Inside my whateverWithStuff constructor, I
retain the object, or allow the implicit retain of the underlying
alloc to remain in place, actually. Now, my state machines and
threads can toss the object about freely, retaining when they hold it,
releasing when they're done, letting their call-stacks fall down
through autorelease pools and back to the user input looop, and never
worrying about the object disappearing prematurely. At the end, the
object itself actually knows (in my case) that it's all used up
(because of its windowWillClose), and that routine autoreleases the
object, eventually discharging the long-standing release obligation
left open back in whateverWithStuff.
This stretches the "at-a-glance" retain/release verifiability a bit,
but at least the retains and releases are balanced within the class.
Some objects explicitly provide a "close" method, or something of the
sort, something that their users are responsible to call when they're
done with the object, and the final autorelease goes there.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
