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.

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.