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 17:19:16 +0200
On Tuesday, August 6, 2002, at 04:35 Uhr, Ondra Cada wrote:
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).
The fact that you consider it idiotic, or that a whole bunch of experts
consider it idiotic as well, or even that it *is* idiotic, does not
make it any less legally binding.
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.
Yes it is. The method itself is 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 are talking about consequences, not the accessor itself. While we
obviously disagree about the consequences, there can be no disagreement
that the simple accessor is actually simpler.
You know, it's just like you can very effectively program in plain C
with plain alloc/free: 'tis more or less the same.
These analogies don't help.
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.
They are not simpler. They actually make things more complicated. The
performance loss is also rather substantial.
What then with (INCORRECT, but -- probably -- correct from your POV)
code of
-(NSString*)title { return title; }
Fine.
-(void)setTitle:(NSString*)str { [title release]; title=[str copy]; }
Why are you making a copy? Where does the method say it will be making
a copy? I didn't tell it to make a copy, I told it do set the string I
gave it as the title. Furthermore, this code seems buggy. If str ==
title (and might be if copy is implemented as retain), then you've got
the classic "released a bit too early" problem?
Why all this complication?
? 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.
Then maybe that is what the caller *wanted* to do? It is not the
library's job to second-guess the user's intention.
(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? ;)
No.
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
This actually is the simplest for a non-retained var.
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.
This should be the simplest thing that could possibly work.
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]; }
Pretty much so.
-(void)dealloc { ... [self setter:nil]; ... }
Don't do that. Why not? A subclass could very well override the
setter to do something "non-simple", in which case you might be
triggering serious computation. Just use [var release]; (beware of
cycles, though).
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!
The ones I use and advocate do fulfill the conract of doing the
simplest thing compatible with the retain/release rules. This can be
documented once, somewhere, but after that, it should be enough to say
"simple accessor".
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.