Re: Accessor methods and (auto)release: conclusion
Re: Accessor methods and (auto)release: conclusion
- Subject: Re: Accessor methods and (auto)release: conclusion
- From: Brent Gulanowski <email@hidden>
- Date: Wed, 7 Aug 2002 00:42:40 -0400
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.
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. 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). But instead of falling in the trap of
academic discussions and religious debates, better spend your time on
writing unit test.
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. 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.
What I find is missing from the various viewpoints is some good
terminology -- so far, I think that the only designations I've seen for
various patterns are "retain/release", "retain/autorelease", "ugly" and
"simple". And maybe "really simple". Not very helpful. Please name these
patterns so we know we are talking about.
Furthermore, it is becoming apparent that there are groups of accessors,
and these must be clearly delineated to avoid labeling certain groups of
accessors to be "exceptions" to the (as yet un-crowned) predominant
pattern, thereby implying the others are "normal" -- a false distinction.
A simplistic term for ivars which are always copied would be "private";
for ivars which are public (and not copied): "shared" or "common". For
things like "super" etc. (also not copied): "infrastructure".
So far I can't find a good reason to pick sides. 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.) If
this is so essential, it should be then build into the language, or some
kind of macro should be built into the framework and pushed heavily to
enforce adoption.
Brent Gulanowski
--
Inkubator: creating free, open source Mac games.
http://inkubator.idevgames.com - homepage
http://www.sourceforge.net/project/inkubator - project page
http://64.246.17.165/forum/forumdisplay.php?s=&forumid=17 - discussion
forums
_______________________________________________
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.