Re: Accessor methods and (auto)release: conclusion
Re: Accessor methods and (auto)release: conclusion
- Subject: Re: Accessor methods and (auto)release: conclusion
- From: Marcel Weiher <email@hidden>
- Date: Tue, 6 Aug 2002 16:29:30 +0200
On Tuesday, August 6, 2002, at 03:59 Uhr, Ondra Cada wrote:
On Tuesday, August 6, 2002, at 03:03 , Marcel Weiher wrote:
I also agree that it is bad practice, because it creates the
expectation that certain things 'usually' work...
Well, I fear I have to disagree here. The "invariant" sounds pretty
reasonable to me:
"You can depend on the fact that a vended object (from a getter) is
valid the whole scope of the current (in the moment the getter was
used) autorelease pool".
Actually, you can't. For example, if the object is mutable, someone
could still change it. Furthermore, the exact scoping of
autorelease-pools seems to be a major point of confusion for newbies.
Furthermore, there are some methods that do handle it this way, and
others that do not. So something very simple (an accessor) starts
drifting off into the neboluous realms of myth and folklore.
"Well, if you retain+autorelease 3 times, then it works, I swear, but
you must do the magic chant, too". Don't say it doesn't happen, we've
already had questions pretty close to this on this very list!
With the accessors you advocate it DOES NOT HOLD TRUE
No need to shout. Of course the simple accessors have no relation to
the scope of the current autorelease pool. They have no need for such
complication.
-- there is a number of situations, often not quite transparent, when
the vended object would "magically" disappear under your hands.
No. The situations are very simple and not magical.
That is, unless you hold it: I don't know whether you use -- IMHO
pretty ugly -- patterns like
id o=[[[foo getter] retain] autorelease];
... something ...
[o whatever];
There is no need to do that.
or
id o=[[foo getter] retain];
NS_DURING
... something ...
NS_HANDLER
[localException raise];
NS_ENDHANDLER
[o whatever];
[o release];
There is rarely if ever any need to do this for accessors (unlike for
-copy or alloc/init allocations), because there is hardly ever a need
to deallocate the containig object while you hold on to a part (and the
accessor iself hasn't messed with the retain-count). If you do hold
onto a part while releasing its containing object, you *should* use an
"ugly" pattern like the one you give, instead of relying on the object
to 'magically' stick around for some not entirely clear amount of time.
The "ugly" pattern shows that you are doing something special, the
retains+releases give a clear indication of what you are doing:
retaining the object for your use, and then releasing it. You are the
client, and you want to hold onto the object. Therefore *you* should
retain it! The rules are simple and clear on this.
Unless you do this (do you?), without correct accessors (as I've
written) your code is prone to err as soon as ...something... happens
to, however indirectly, use the setter or dealloc the foo.
No, it isn't.
That is not quite robust programming in my vocabulary.
Relying on an accessor to retain an object for you is not robust
programming in my vocabulary, and a clear violation of the simple
object-ownership rules.
I much rather lose a few ticks where I don't need them (ie. in the
"return [[ivar retain] autorelease]" getter) than either having to use
the ugly patterns shown above next to anywhere, or having always to
check in very thorough details the entire ...something... -- whenever
the code is changed when maintaining the program -- to be completely
sure that its triple hidden sideeffect can't be the setter or foo
dealloc!
I rather make sure my code doesn't have triple-hidden side effects like
that, rather than have ugly side-effects like that hidden by a couple
of extra autoreleases sprinkled all over the code.
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.