20 messages in net.java.dev.rococoa.usersRe: Rococoa Retain and Release| From | Sent On | Attachments |
|---|---|---|
| Duncan McGregor | Jul 27, 2009 8:48 am | |
| Michael Nagel | Jul 27, 2009 9:29 am | |
| Duncan McGregor | Jul 27, 2009 12:44 pm | |
| David Kocher | Jul 27, 2009 3:35 pm | |
| Duncan McGregor | Jul 27, 2009 3:43 pm | |
| David Kocher | Jul 27, 2009 4:08 pm | |
| Andrew Thompson | Jul 27, 2009 7:02 pm | |
| Michael Nagel | Jul 27, 2009 9:28 pm | |
| Duncan McGregor | Jul 28, 2009 1:29 am | |
| Duncan McGregor | Jul 28, 2009 3:42 am | |
| Duncan McGregor | Jul 28, 2009 4:07 am | |
| Duncan McGregor | Jul 28, 2009 4:33 am | |
| Andrew Thompson | Jul 28, 2009 4:41 am | |
| Duncan McGregor | Jul 28, 2009 5:01 am | |
| Duncan McGregor | Jul 28, 2009 11:55 am | |
| Andrew Thompson | Jul 28, 2009 6:17 pm | |
| Duncan McGregor | Aug 10, 2009 3:28 am | |
| Andrew Thompson | Aug 10, 2009 8:56 pm | |
| Duncan McGregor | Sep 1, 2009 7:59 am | |
| Andrew Thompson | Sep 1, 2009 6:12 pm |
| Subject: | Re: Rococoa Retain and Release | |
|---|---|---|
| From: | Duncan McGregor (dun...@oneeyedmen.com) | |
| Date: | Sep 1, 2009 7:59:42 am | |
| List: | net.java.dev.rococoa.users | |
On 11 Aug 2009, at 04:56, Andrew Thompson wrote:
On Aug 10, 2009, at 6:29 AM, Duncan McGregor wrote:
I really don't know. Cocoa classes that rely on release for clean- up are just not going to work when run under ObjC GC, because under GC, release is just not called.
Well, it would be if I wrote code that explicitly called it. That's to say if there is some class Foo with a meaningful release method, and MyBigApp (being written before garbage collection) calls foo explicitly, then turning on GC may not immediately break things because my code still contains [someFoo release] all over the place. NSObject's release is a no-op, but I believe nothing stops me from calling it myself.
This is theoretically true, but practically, you don't override release, you override dealloc. Then your code doesn't call dealloc explicitly, only as a result of release moving the count to 0.
I bet as soon as Foo gets near an autorelease pool, everything goes horribly wrong however, as I'm assuming these are a no-op under GC?
I believe so.
So I'm guessing that Apple must have made sure that there are no instances of release tidying for the core classes. I use CFRetain and CFRelease on Mike Swingler's advice, because they retain and release when reference counting, and mark the object as not eligible for GC under GC. That said, under GC, where I don't retain because we own the object (alloc etc) I'm guessing that we will just crash.
Oh dear. Probably really ought to try to fix that. Then again, the idea of two garbage collectors makes my brain ache. I am thinking you are very probably correct here. The core libraries will be clean and everything else will have to be cleaned up to be GC safe eventually anyway. So maybe not worth us twisting things just to deal with (hypothetical!) legacy code.
Pity the poor developer.
I'm inclined to say that, as classes that rely on release for tidy up are fundamentally broken wrt ObjC GC, its OK that we don't call release. Then we could:
1. Remove release from our NSObject, 2. Leave it in but never pass it through the proxy 3. Move the memory protocol to an interface that our proxies implement but our NSObject doesn't, so that if you really need them you can cast to it and use it
Hrm... I'm mostly indifferent. 3 looks attractive, but then one is making a part of the API of the proxies public and committing to it, which seems like a bad idea for future flexibility. Someone one might regret?
Maybe 2. and then if we discover we've made a horrible blunder we can let it through again later?
I favour 3, but maybe after 1 so that we can see if anyone complains.
D