|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:||Rococoa Retain and Release|
|From:||Duncan McGregor (dun...@oneeyedmen.com)|
|Date:||Aug 10, 2009 3:28:49 am|
On 29 Jul 2009, at 02:17, Andrew Thompson wrote:
Ah, see, I knew I was missing something obvious. That explains the initialization code I was reading too, where you retain autoreleased objects but not alloc/init or new'd objects. So it all balances out.
When it works!
I have to say, in the code I've written this design decision completely passed me by. Probably because I always prefer autoreleased constructions like 'stringWithString' wherever possible.
But as I wrote more code I would inevitably have eventually called an alloc/init pair and then happily called release on it assuming I had to do so.
So, personally I'd say making release a no-op is probably your best bet. A couple of reasons:
i) it's what apple did with objective c garbage collection ii) classes might reasonably call super.release() so it should probably exist
Actually, I've realized something ... in finalize you call CFRelease.
But, what if people have written subclasses that do work by overriding -release? e.g. closing streams or files or whatever before calling [super release]?
Aren't we risking not calling that code? Should the finalizer be trying to send a release message to the class?
That's why Apple no-op'd -release I suspect, because existing classes, especially. 3rd party ones could be relying on it still being called by client code.
That would suggest making NSObject's release a no-op (by intercepting it in the plumbing of Rococoa, thus avoiding special casing any templating engine?) That way the finalizer could send a -release message and then CFRelease to actually clean up.
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. 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.
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
In all three cases if you need to affect the count, you can always fall back on Foundation.cfRetain and cfRelease