Re: Accessor method styles

FROM : Shawn Erickson
DATE : Tue Aug 29 17:15:12 2006

On Aug 29, 2006, at 7:53 AM, Andrew Merenbach wrote:

> Hi, all.  I've seen threads where this has been beaten to death, 
> but I am still left with major questions.  I have seen several 
> kinds of accessor/mutator methods:
>
> - (void)setFoo:(AMFoo *)aFoo {
>     [aFoo retain];
>     [myFoo release];
>     myFoo = aFoo;
> }


Usable for a retain based setter but not for a copy based setters. 
(so if you change your mind you have to rewrite the setter)

> - (void)setFoo:(AMFoo *)aFoo {
>     id oldFoo = myFoo;
>     myFoo = [aFoo retain];
>     [oldFoo release];
> }


Usable for a retain based setter or for a copy based setter.

> - (void)setFoo:(AMFoo *)aFoo {
>     if (aFoo != myFoo) {
>         [myFoo release];
>         myFoo = [aFoo  retain];
>     }
> }


Avoids messaging overhead and locking related to retain count 
management in the case that aFoo and myFoo are the same. If your code 
is likely to do that a lot then this is a win otherwise it has near 
zero net effect (branching is small compared to messaging overhead). 
Additionally setters can often be a place to trigger processing (say 
redisplay) related to the new value that was set. The use of the if 
check in the above fits will with avoiding unneeded processing when 
the object being set is the same as what is currently set. I 
personally use this type of setter the most often... found that it is 
the one the best supports addition of set related logic when you find 
you need it down the road. Usable for a retain based setter or for a 
copy based setter.

> - (void)setFoo:(AMFoo *)aFoo {
>     [myFoo autorelease];
>     myFoo = [aFoo retain];
> }


Allows the old myFoo to continue to exist past the set call if this 
object was the only one holding a retain. In other words the code 
that sent setFoo maybe have asked for foo before the set message and 
the act of sending the set message could in validate the reference 
that code has. Of course code that depends on this is fragile and 
explicit retains or reorganization of the code should likely take 
place. Since it continues to exist in the current autorelease pool 
this type of setter extends the window of time that the memory 
related to the old myFoo is in use which could increase memory 
pressure in your application. Usable for a retain based setter or for 
a copy based setter.

Also don't forget some object setters don't retain or copy (often 
used for weakly referencing things like a delegate).

My 2 cents,
-Shawn