On Tue, Apr 27, 2010 at 1:49 PM, Bill Appleton <billapple...@dreamfactory.com> wrote: >>> Over the years, I think that looking at the retain count is the #1 cause > of hairpulling on this list. > > > it's too bad this is unreliable > > an object should be able to return this info
Why? It serves you no purpose. Once you hand an object off to the framework, how do you know what it does with that object? > and it isn't simple, it gets convoluted in process > > if i add a submenu to an item then it is retained by the menu > > but then if i then set that submenu to nil is it still retained? Don't focus on the object itself. Focus on your reference to the object. If you want to hold a reference for a while, you need to retain the thing that lives on the other end of that reference. When you no longer need that reference, you release the thing at the other end of the reference. The reference is a cable to which a valuable object is attached. Your hands are concerned about holding on to your end of the cable. > if retained count was accurate you could test it on final release, etc The retain count *is* accurate; it accurately accounts for every -retain/-release pair that has been performed on that object, whether you performed it or not. --Kyle Sluder _______________________________________________ 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 arch...@mail-archive.com
