Accessors
Accessors
- Subject: Accessors
- From: Marcel Weiher <email@hidden>
- Date: Wed, 7 Aug 2002 10:11:52 +0200
On Wednesday, August 7, 2002, at 06:42 Uhr, Brent Gulanowski wrote:
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.
Accessor: a method that provide access to instance variables, and no
more.
Accessors are replacements for direct access to instance varibles. Why
not access the instance variables directly? Because the object may
change in the future in such a way that accessing that instance
variable directly is no longer appropriate. So accessors are a way of
dealing with future change, if you're code is never actually going to
change, you wouldn't need accessors. (Note that this is different from
*thinking* that your code is nevery going to change... ;-)
Why "no more"? Most methods access instance variables in the process
of doing their thing. If we called all of these methods accessors, the
term would be useless. The term accessor is reserved for those methods
that really just provide plain access to the instance variables.
What do accessor look like? Well, in the simplest case, they return
and set the instance variable, respectively:
-(int)var { return var; } // CORRECT
-(void)setVar:(int)newVar { var = newVar; } // CORRECT for
non-objects
This sets an integer instance variable. This is a simple accessor
(Well, I don't see how it can get any simpler...)
That's really it...
...if it weren't for Foundation\s reference counting scheme for
objects. This means that the simple accessor given above is not quite
sufficient:
-(void)setObject:newObject { object = newObject; } // WRONG for (most)
objects!
Instead, you have to retain the new reference, and release the old
reference. (You have to do it in that order to avoid nastiness when
newObject == object ).
-(void)setObject:newObject // CORRECT
{
[newObject retain];
[object release];
object=newObject;
}
If we had language support for garbage collection, this wouldn't be
necessary, and the object-accessor could look like the simple accessor
for integer variables above.
One could argue that even this simple setter method is *not* an
accessor any longer, because it does more than just set the instance
variable. However, due to the fact that this idiom is the minimum you
can do within the rules of Foundation's memory management rules, which
are our "poor man's garbage collection", it is probably acceptable for
this to be considered an accessor.
So to sum up, everything so far is a "simple" accessor (with the
non-object version being "really simple"). Many of the "old hands"
here seem to agree that that is all that is needed. I would say that
even using the term "accessor" for something that goes beyond this is
at the least misleading.
The "accessor extensions", such as autoreleasing on set,
-(void)setObject:newObject // autorelease-on-set
{
[object autorelease];
object=[newObject retain];
}
or autoreleasing on get
-(void)object { return [[object retain] autorelease]; } //
autorelease-on-get
have been proposed in order to work around problems (bugs) in client
code. Many of the "old hands" here seem to agree that it isn't the job
of the accessor to work around (rare) client bugs. In fact, it is
downright harmful to do so because bugs that need to be fixed for other
reasons remain hidden.
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,
Well, as is obvious by Ali's comments, the "extended" patterns are
actually new, the "simple" patterns are what is currently "normal" even
in Apple code. Many of the "old hands" here also seem to agree that
the "simple" pattern is the "normal" one. That is all I can offer.
I like Ondra's argument to keep the "retain/autorelease" stuff
localized to avoid re-typing it a lot (and thereby forgetting it
somewhere)
Well, you don't have to retype a lot, because the pattern is actually
quite rare, despite what Ondra claims.
, but why would I trust that everyone would follow it?
Exactly. You shouldn't. The new pattern tempts you to ignore the
retain/release rules in some specifiic circumstances that are hard to
delineate clearly, especially since there are and will remain objects
that don't follow this new pattern.
Furthermore, it is "localized" in the wrong place. It should be
localized in those rare (client-side) locations where the problem
occrs, not spread randomly all over the code "just in case" there is a
client that is buggy.
(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.
See the accessor-macros provided in MPWFoundation...
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.