On 27.04.2010, at 22:49, Bill Appleton wrote: > an object should be able to return this info > > and it isn't simple, it gets convoluted in process
Let me exaggerate for a paragraph to hopefully bring across a point: The main objective of Cocoa's design is not to produce the most efficient code (for that you'd write your whole application in assembler), or to write code where everything is set in stone at compile-time (for that you'd use C++). The main objective of Cocoa's design is to make it easy to write object-oriented, modular, encapsulated software. And encapsulation is exactly what looking at the retain count violates. In an ideal world, every subsystem of your program would be completely self-sufficient and independent of the rest, to make it easy to thoroughly test it. The problem is that no real-world program fits this description. The idea behind retain counting is that each subsystem only has to care about itself, about the reference(s) to a shared resource that *it* holds. It does not (and actually, should not) have to care about references anyone else holds to the same resource. As long as everyone else obtains and gives up their references properly, the resource eventually is reclaimed. And this holds true not just for the traditional concept of a subsystem, but also for each subroutine as a "micro-subsystem". There is documentation about who retains what. The memory management documentation mentions some of it (the naming conventions for methods), there's a convention that, generally, you do not retain your owner (because it very likely already retains you and you don't want closed circles because then you'd never get released), so generally delegates aren't retained. I'm not saying there aren't bugs. For example, bindings were notorious for causing retain circles when you bound to File's Owner in a NIB, and that was fixed in 10.5, IIRC. But generally, documentation informs you of this. And when it doesn't, people have usually figured it out using Instruments, or by following the calls to retain/release/autorelease on an object. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de _______________________________________________ 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
