On Monday, June 02, 2008, at 11:35AM, "Paul Sargent" <[EMAIL PROTECTED]> wrote: > >On 2 Jun 2008, at 18:50, Bill Bumgarner wrote: > >> While learning the retain/release paradigm is certainly useful, it >> is considerably more complex than GC. It is also unnecessary while >> learning Cocoa. Specifically, GC is intended to be a production >> quality solution that you can use in your Cocoa applications, >> without exception. In Leopard, there have been a handful of bugs >> and they have been addressed through software updates -- not >> surprising given the rather sweeping and intrusive set of changes >> needed to support GC. And GC will get better / faster in future >> releases. > >I agree with nearly everything you've said, except the (second half of >the) first statement. > >I wouldn't say retain/release is more complex than GC. I'd say using >retain/release in a medium->large size project is more complex than >using GC, but the base concept is a simpler one. Whilst learning, >getting retain/release wrong tends to be less confusing than getting >GC wrong. GC will make things disappear at random times, whereas >retain/release will tend to be deterministic in behaviour.
In GC, you keep things around by referring to them and they get cleaned up automatically when they are no longer referenced. If you want to casually refer to something, you can use a __weak reference (sorry, GCC made us __do __it) and the collector will automatically set your reference to nil when there are no more strong references. Furthermore, as soon as you throw threading into the mix, GC remains dead simple while non-GC becomes rather nastily complex. Specifically, non-GC requires that you consider the "threaded ownership" of an object in that every thread has its own isolated autorelease pool. In other words, it is impossible to pass "ownership" of an object from one thread to another in some kind of automatically-released-if-not-needed-further fashion. Without locking, you can't write a safe, atomic, non-GC setter method. And if you want to not run the risk of deadlocks, you need to also deal with exceptions, too. This is the reason why @property(atomic) is a boatload slower than @property(nonatomic) under non-GC -- there is a lot of subtlety to ensuring atomicity of object assignments in this case. GC makes all of that automatic. In GC, an assignment implies ownership and there is no race condition involved. Nor are there any per-thread ownership issues to deal with when passing an object from one thread to a next. So, no, I don't buy for a moment that non-GC is simpler than GC. The case the OP had is an edge case and, with a bit of thought, becomes fairly obvious what has gone wrong; the object is being collected because nothing is referring to it. Note that the application did not crash, as would be typical in the non-GC case. Given that the OP had to be manually loading a NIB in the first place in a context that is both not the main NIB file and not in a document based application, said NIB loading pattern is definitely moving outside of the realm of rank beginner. Certainly, there could be better support -- a better out of the box pattern -- for dealing with the loading of auxiliary nibs. >That's how all the senior programmers on this list learnt (although >they didn't have a choice). Why do we think that people following can >jump a few steps? Because it wasn't possible to jump said steps when most of us learned to program Cocoa. Reference counting based development is an anachronism within Cocoa programming. A very important, very well supported, anachronism. Reference counting will be around for a long long time to come, certainly, but there is absolutely no reason to use reference counted based Cocoa development save for legacy reasons and a handful of project types that really really need the absolute and total determinism of a reference counted system (of which, "when -dealloc is executed" should not be a consideration). There are actually a number of very solid performance and maintainability reasons to avoid retain/release/autorelease. 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 [EMAIL PROTECTED]
