On Fri, Jun 26, 2009 at 5:40 PM, James Gregurich<bayoubenga...@mac.com> wrote: > I really don't get this whole line of reasoning. I don't get why the fact > that a system keeps an NSFont around justifies me adding a whole new system > to scan memory and look for pointers to determine which ones need to be > released.
That wasn't where I was going with that. I was making two distinct points: 1) You can't depend on any Cocoa object actually getting released at any time. 2) Garbage collection is a useful facility that doesn't solve all problems but makes the most common ones much easier to solve, since you don't have to worry about manual memory management. > If the system decides to keep an NSFont around, that is its business. but if > I need a hierarchy of my own classes to go away in a well-defined order at a > precise time, then I want that control. I don't want a background process > deciding at some arbitrary time where the objects are released. You don't have that control with -retain/-release as it is. The system might at any point arbitrarily decide to hang on to objects that you intend to manage yourself. It seems like you're trying to apply an RAII-like pattern to dealing with Cocoa; Cocoa just doesn't work this way. The occasions where you need objects to "go away in a well-defined order at a precise time" should not be handled by memory management. You should have a separate resource management paradigm for these sorts of objects, like NSFileHandle (to pick one example) does. Cocoa very intentionally does not conflate the concepts of object lifetime and resource acquisition. >> The creators of garbage collectors don't consider them to be >>panaceas. There are a very well known class of problems which GC >>utterly fails in. There's also a rather large class of problems which >>can only be solved (that is, solved by a programmer within a normal >>human lifespan) with some form of automatic garbage collection. The >>Lisp guys can probably come up with boatloads; after all, they've had >>since the late 50's. > > > really? > > I'd find it interesting to see a list of problems that require a garbage > collector to manage the memory. Perhaps you could provide that. Closures are notoriously hard to implement without some form of automatic memory management. Forgetting everything announced and unannounced about upcoming features of ObjC, we have a small version of this issue right now, when dealing with NSBeginAlertSheet context pointers. Also, NSWindowController and NSViewController require special voodoo to break retain cycles in NIBs. This logic is unnecessary in a garbage-collected environment. None of these are insurmountable, to be sure, but they are a lot easier with garbage collection. --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
