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 15:03:47 +0200
On Tuesday, August 6, 2002, at 02:45 Uhr, Marco Scheurer wrote:
The case for the [[object retain] autorelease] pattern was already put
forward by Ali in a previous message:
Yes, I had seen that, but have to admit I was too lazy to rebut it
point by point... ;-)
I am concerned about the more subtle case such as:
str = [myWindow title];
...
[myDocument saveDocument];
...
... use str ...
Assuming myDocument is the document in myWindow, a side effect of the
"saveDocument" call might be to release the title you got back in the
first line. A retain/autoreleased return from the first line would
eliminate this potential issue, which could be hard to debug.
It's also possible to build an example here of why Method 1 (setter
does autorelease) could be bad in this situation. Consider, if
saveDocument was implemented as:
pool = [[NSAutoreleasePool alloc] init];
...
if (isUntitled) {
...put up save panel, get new name...
[myWindow setRepresentedFilename:newDocumentFileName];
}
...
[pool release];
I am assuming here that setRepresentedFilename: ends up changing the
title of the window. In this case, due to the nested autorelease
pool, even if the setTitle: method did an autorelease, the value will
still be released when "str" is accessed in the outer function.
I do not think that this a very good reason. It is true that the "str"
code above could crash if str is freed before it is used, but making
NSWindow's title return a retained/autoreleased version of the string
is just a hack. It will not, in all probability, correct the code as
written, but only remove the symptom (the crash):
- If the programmer wants a copy of the original window's title, he
should do just that,
str = [[window title] copy];
- If the programmer wants a reference to the actual window title, he
should make sure that this reference is valid. In that case, as
explained above, a retain might not be enough if the window's title is
changed before str is used.
I don't see what other meaning this code can have, and in both cases
the retain/autorelease pattern is useless.
The other reason offered for this pattern ("more thread safe but not
quite enough") is also invalid. Using this pattern for that purpose
will only make errors harder to detect and correct.
I tend to agree with Marcel that this is an unnecessary obfuscation
and performance penalty. Based on the reasons given for its use
above, I would even say it's bad practice. Since the apparition of
retain/release/autorelease in OPENSTEP I've used the simple accessors
methods, with no autorelease in the getter nor the setter (nor
dealloc!), and this has never been the source of a problem. Maybe I'm
missing something...
Thank you for making the point much clearer than I had managed to do!
I also agree that it is bad practice, because it creates the
expectation that certain things 'usually' work, except that sometimes
they don't, and you can't really tell when they do work and when they
do not. Sometimes, an honest failure is better than something that
magically and unpredictably works, sort of, maybe if you look at it
right, some of the time. Software is already unpredictable enough as
it is, making it more so is not an improvement, even if the magic can
sometimes gloss over coding errors.
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.