Re: Accessor methods and (auto)release: conclusion
Re: Accessor methods and (auto)release: conclusion
- Subject: Re: Accessor methods and (auto)release: conclusion
- From: Simon Stapleton <email@hidden>
- Date: Wed, 07 Aug 2002 08:03:14 -0500
On Wed, 7 Aug 2002, at 00:42:40 -0400, Brent Gulanowski wrote:
On Tuesday, August 6, 2002, at 03:53 PM, Georg Tuparev wrote:
This is very interesting -- byt academic -- discussion. I am sure many of
the not so experienced subscribers to this list are now afraid of
touching accessor methods.
I hope not. Really.
Here my humble 12 years NeXTstep/Cocoa experience. In over 95% of the
cases the simplest possible solution discussed in Hillegass' book (pp. 59,
"Retain, Then release") works perfectly.
This is very true, but in the other 5% of cases it becomes necessary to do something more complex, and then (I hope) the contents of this thread will be useful, for 'newbies' and experienced programmers alike. Even if it doesn't provide a cut & dried answer (and I, personally, believe there is no one answer), it should at least trigger a few 'Oh, it's one of _those_ cases' moments.
In the very few cases where
this does not work, you get to know it very quickly (SIGBUS is just one
expression of this knowledge).
<grin> Of course, a SIGBUS in testing is one thing, but in delivered code it's quite another.
But instead of falling in the trap of
academic discussions and religious debates, better spend your time on
writing unit test.
I'm 100% with you here, Georg, but then I fall into the 'extreme programming' camp...
George,
With all due respect, I don't quite agree. As a very attentive newbie,
this issue is very important to me, striking right to the heart of both
OOP principles and Cocoa practice. I want to get it right now, not come
back to it in a few years after I've written quite a bit of code.
A very laudable aim.
While
some people seem to take it for granted that code should be re-written, I'
m not one of them, and I want every method I compose to have sound
reasoning behind every decision I make while designing it.
As is this. Sadly, code _does_ get rewritten (and if you use extreme programming, it tends to get rewritten a lot), as designs change on the fly all the time. Users tend to come back with comments like 'it would be really nice if...' and 'oh, what I really meant when you were gathering requirements was...' and 'no that's not right at all'. All of which have a distinct tendency to require major structural changes. Nasty things, users. If only we could (auto)release them ;-)
So far I can't find a good reason to pick sides.
Nor me.
I like Ondra's argument
to keep the "retain/autorelease" stuff localized to avoid re-typing it a
lot (and thereby forgetting it somewhere), but why would I trust that
everyone would follow it? (Aside from my prior ignorance, of course.)
I think, and I hope I'm not stepping on toes here, that what Ondra was aiming at was the point that no code, other than accessors, should _ever_[1] directly access instance variables. This is a 100% good pattern, IMHO, and what accessors you happen to be using should make no difference.
[1] There are, of course, times when you might have to bypass this for performance reasons. Real life, as ever, pokes its nose into a nice theoretical discussion...
In a related note, I also tend to agree with Ondra about the use of accessors in -dealloc, as well, but then I don't consider -dealloc to be an accessor.
Of course, there are accessors and accessors. For complex cases (i.e. with side-effects), I tend to have 'public' accessors, declared in the header file, which do all sorts of things as well as access the instance variable(s) in question, and 'private' ones in separate, non-published, categories which actually do the real accessing.
Thus, you _might_ have:
// public accessor
- (void) setMyThing: (Thing *) aThing {
if (![[self myThing] isEqual:aThing]) {
[self privateSetMyThing:aThing];
// side effects, such as...
[[NSNotificationCenter defaultCenter] postNotificationName: MyThingDidChange object:self];
[self incrementThingChangeCount];
// etc..
}
}
// private accessor - quite simple and possibly generated by a macro
- (void) privateSetMyThing: (Thing *) aThing {
[[self myThing] autorelease];
_myThing = [aThing retain];
}
- (void) dealloc {
[self privateSetMyThing:nil]; // note use of private method here to avoid
[super dealloc];
}
...but this is, of course, not the simple case. It gets even nastier when you start taking thread-safety into account (and your unit tests get even nastier still), but it's still possible to encapsulate all the accessing into one place, which is part of what OO is supposed to be about, no?
And then, in a separate email, he asked:
Chris Hanson wrote:
Right. We need to start talking in terms of "attributes" and
"relationships."
"Attributes" are other objects owned by an object. "Relationships" are
other objects referenced by an object.
In UML is this the distinction of whether the diamond in the "has a"
relationship is outlined or solid?
Yep.
Just my b,0.02 of gasoline on the fire.
Simon
--
PGP Key Id : 0x50D0698D
--
Your mouse has moved. You must restart Windows NT for this change to be recognised.
_______________________________________________
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.