On Apr 27, 2010, at 1:49 PM, Bill Appleton wrote: > it's too bad this is unreliable > > an object should be able to return this info
An object does return this info, the problem is that the # is a meaningless internal implementation detail of the Cocoa frameworks. For example, if you create an instance of NSNumber, you might actually get an allocated instance or you might get an additional reference to an already existing implementation. With NSString, you might get a constant string (i.e. retain counts are entirely meaningless), a cached instance of one of the more common strings, a substring of one of the former two, or you might get a new allocation. NSImage may or may not return a new instance depending on cache availability. Similarly, when you give an object to any API in the framework, what the framework does with it internally is an implementation detail and one that might change from release to release. When you create an NSMenuItem instance and hand it off to the framework, it might be retained once, twice, 10 times or not at all (remember: if you want to keep an object around, you need to maintain a retain on it). All of this is why trying to do debugging on absolute retain counts is a waste of time. > and it isn't simple, it gets convoluted in process As do the implementation details of most highly optimized complex software systems.... > 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? Maybe so, maybe not. Implementation detail. Maybe it is retained until the next pass through the main event loop? Maybe it is pushed into the autorelease pool? Maybe the retain is held for as long as some internal structure is kept about. The point is that you don't know, can't know, and shouldn't care. The absolute retain count is irrelevant. > if retained count was accurate you could test it on final release, etc The retain count is accurate. Is always accurate. It is just that the value of the retain count may be influenced by factors well beyond your control. All you care about is the retain count delta. "My code caused the retain count to increase by 1, therefore my code *must* decrease the retain count by 1." "My code is 'passing' a reference to this object from thread A to thread B, therefore I *must* have an explicit retain in A and a release in B." Frankly, the -retainCount method should be deprecated and, eventually, removed. b.bum _______________________________________________ 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
