Re: Accessor methods and (auto)release: conclusion
Re: Accessor methods and (auto)release: conclusion
- Subject: Re: Accessor methods and (auto)release: conclusion
- From: Marco Scheurer <email@hidden>
- Date: Tue, 6 Aug 2002 16:46:58 +0200
On Tuesday, August 6, 2002, at 03:59 pm, 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".
With the accessors you advocate it DOES NOT HOLD TRUE -- there is a
number of situations, often not quite transparent, when the vended
object would "magically" disappear under your hands.
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];
or
id o=[[foo getter] retain];
NS_DURING
... something ...
NS_HANDLER
[localException raise];
NS_ENDHANDLER
[o whatever];
[o release];
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.
Come on! I'm sure you often use the following:
id object = [[[array lastObject] retain] autorelease];
[array removeLastObject];
[object whatever];
You have to, because for some reason (performance), collections are
excluded from the retain/autorelease pattern. Nobody would object to
that kind of code, and it is not different than the "ugly" patterns
above. So yes, I'm using these constructs, when they are needed, not
everywhere. I also try to rewrite the code so that they are unnecessary,
if possible.
Of course you've got to know what you're doing. I can imagine cases
where a reference is "disappearing" because of "something", that I did
not know about it, and I have a problem. But as I explained in the
[window title] rebuttal, retain/autorelease is probably not the
solution, more likely only a hack to make the symptom go away. What's
the point of blindly holding onto the wrong object?
BTW, why is this retain/autorelease uglier here than in a getter?
Because in a getter it's more or less hidden, you can forget about it,
while it may be obfuscating a bit an algorithm code?
Now, since collections are definitely excluded from the accessor pattern
you advocate, your "invariant" does not hold either. Sometimes (most of
the times I would say) you have to use the "ugly" construct anyway.
What's the point then?
That is not quite robust programming in my vocabulary. 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!
Only if your focus in robust programming is "code that does not crash"
rather than "correct code".
If my program does not have to return correct results, I swear I can
write it so that it will not crash, does not leak, and be very fast.
Marco Scheurer
Sen:te, Lausanne, Switzerland
http://www.sente.ch
_______________________________________________
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.