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 _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
