Re: Accessor methods and (auto)release: conclusion
Re: Accessor methods and (auto)release: conclusion
- Subject: Re: Accessor methods and (auto)release: conclusion
- From: Ondra Cada <email@hidden>
- Date: Tue, 6 Aug 2002 16:35:42 +0200
On Tuesday, August 6, 2002, at 02:14 , Marcel Weiher wrote:
On Tuesday, August 6, 2002, at 01:56 Uhr, Ondra Cada wrote:
On Tuesday, August 6, 2002, at 10:34 , Marcel Weiher wrote:
Well, you shouldn't be: almost all countries nowadays have patent
agreements meaning that they recognize each other's patents. Don't
assume that you're immune from US patents just because you don't live
there.
Well, I feel this is somewhat OT here. If anybody wants to discuss this,
please check archives first -- there was a thorough discussion of the U.S.
patent law not long time ago (whose result was that the thing is a
definite crap good for nothing, since it allows to patent such things as
garden swing or /this one's actually Australian/ a wheel). I really doubt
Apple would sue me for using autorelease pools in GNUStep (or in my own
XSdk libraries for Epoc) -- well if they do, it might be interesting.
Being no lawyer, I won't participate in this debate anymore.
well, I understand this reasoning, but personally like more the one Ali
and I have presented (incidentally, I use autorelease-based patterns
very very happily for ten years in many hundreds of thousands lines;
never I have an accessor-based retain problem!).
Well, I do *not* use the autorelease-based pattern, have been programming
Objective-C for over 15 years (yes, before NeXT was introduced, and
obviously I have been using Foundation and retain/release for not quite
as long) and also have never seen a problem. So I guess that is about
even.
However, since the non-autorelease-based one is simpler and faster, it
wins ;-)
It might be faster; it is very definitely not simpler. With proper
accessors, you don't need to consider whether the subsequent code might or
might not release the vendor object, whether it might or might not use the
setter itself. With the plain accessors you advocate, you have to. That's
not simpler, quite the contrary.
You know, it's just like you can very effectively program in plain C with
plain alloc/free: 'tis more or less the same. Autorelease pools are, like
objects themselves, retaincount-based garbage collection, exceptions,
notifications, and many many other things, just another case of a hi-level
(and thence of course relatively complicated) tool, which though allows
for simpler and more robust programming -- at the price of some (generally
unimportant) efficiency lose.
(b) things like -title/-setTitle: I call accessors too; you have to
invent another name for them (if needed);
Well, that depends on wether they access an instance variable (in which
case they're accessors). If they don't access an instance variables,
they're not accessors. It's sort of in the name..
(c) for them, those patterns I've presented (namely, using copy) are
very very practical;
Copying is fine as long as it isn't done in an accessor.
What then with (INCORRECT, but -- probably -- correct from your POV) code
of
-(NSString*)title { return title; }
-(void)setTitle:(NSString*)str { [title release]; title=[str copy]; }
? They very directly access an instance variable, thus -- as you said --
they are accessors. The setter does copy, and I do claim that in this case
it is exactly what it *should* do, for cases when the caller happens to
use a shared mutable string for the setter's argument.
(d) if you, in the class documentation / commented headers whether the
particular setter/getter autoreleases or not and whether it copies or
not,
there would be no harm anyway.
Well, it seems that the default should be to do nothing and not document
doing nothing. If you decide to do something, then you should document
that you're doing something ;-)
Ammm, is this a word game, or what? ;)
If you literally do nothing, of course you don't document anyhting.
If you do *something* though -- like setting or vending an ivar -- you
should do that the standard way. Very definitely it is not the simplest
one, for it would look like
-getter { return ivar; } // this you like
-(void)setter:o { ivar=o; } // I bet this you don't like
What we need is find which of all the possible ways is the "right", or,
rather, *standard* one. This standard way needs not to be documented; any
other one *SHOULD* be documented.
It seems now that the standard way for Cocoa is this:
-getter { return [[ivar retain] autorelease]; }
-(void)setter:o { if (ivar==o) return; [ivar release]; ivar=[o retain]; }
-(void)dealloc { ... [self setter:nil]; ... }
or, naturally, anything *functionally equivalent* -- in other words,
fulfilling the agreement "the vended object would be valid (at least) in
the entire scope of the autorelease pool (current in the moment the getter
vas used)". Those plain accessors you advocate alas are not!
You don't have to like it, and you don't have to use it either;
neverhteless, if you are writing a class which DOES NOT fulfil this
agreement -- and, if there is the remotest possibility the class would be
used by any 3rd party, of course -- you should document it. That's all.
---
Ondra Hada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
_______________________________________________
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.