accessors

0 views
Skip to first unread message

Byron

unread,
Nov 13, 2009, 3:21:59 PM11/13/09
to iPhone Application Development Auditors
Ok so this may be simple stuff but i haven't been programming for long
and i just cant get my head around accessors (setters and getters) i
know how to write them in code and i know how to use properties and
synthesise. i thought that as i use them again and again i will start
to understand what they do and why we use them but i cant understand..
even after reading a few guides.

what i dont understand is in the code below we are firstly getting the
ivar yes? what is the purpose of this? and in the second part (the
setter) i read this and it is setting name to value if name doesnt
equal value? and why release name if were setting it?

say i have a property list and i want to initialise an array with the
contents of this file is the setter method where i would do it? i am
finding it hard to get my head around the purpose of these accessors
and how to use them so if anyone could help out it would be much
appreciated.

Thanks
Byron

- (NSString *)name {
return name;
}

- (void)setName:(NSString *)value {
if (name != value) {
[name release];
name = [value copy];
}

AppleMike

unread,
Nov 13, 2009, 5:41:39 PM11/13/09
to iPhone Application Development Auditors
Hey Byron.
Sure I'll take a crack at it.. :)

In XCode, it is convention to use the name of the ivar as the method
name. This is perhaps why it looks weird.
You're just returning the ivar 'name' using a method that happens to
be named the same as the ivar. This allows for other
cool tricks like Key-Value Coding and Key-Value Observing. Examples:

[myObject name]
myObject.name

Using this convention, it's very clear which ivar you are asking for.

As for the setter methods, the one you are showing is the Copy setter
(e.g. @property (copy) name; )

The reason for checking first is if by some strange twist of fate, the
parameter is the same as the ivar.
WIthout that 'if' statement above, assuming value == name means when
you release name, value is nil. Then you assign nil to your ivar.
Probably not what you wanted.

As for your array question, it's easiest (and recommended for the
iPhone by Apple) to specify the array as a property with attributes
(nonatomic, retain), and then synthesize it in your implementation:

Atomicity has to do with how the ivars are handled in a multi-threaded
environment. By specifying 'nonatomic', you are simply returning the
value and not using locks during the operation.
By specifying 'retain', you are telling the compiler to create the
setter method for you using a "release-retain" model, something like
this:

- (void) setMyArray: (NSArray *) newMyArray {
if (myArray != newMyArray) {
[myArray release];
myArray = [newMyArray retain];
}
}

The default attribute for @property is (atomic, assign), which makes a
direct assignment
Also there is the (copy) attribute, which does like your code showed,
copies the parameter to your ivar.

Hope that helps.

More info on this in Apple's "The Objective-C Programming Language"
and "Memory Management Programming Guide".

@Mike

Byron

unread,
Nov 14, 2009, 4:05:41 AM11/14/09
to iPhone Application Development Auditors
Thanks AppleMike, your explanation has indeed helped me loads, the
method name being the same as the ivar is confusing but i see now how
useful it is.

thanks again and i shall check out the links too

Byron

squirlyfox

unread,
Nov 14, 2009, 11:34:17 AM11/14/09
to iPhone Application Development Auditors
Having the method name the same as the ivar can be confusing (and can
potentially cause unwanted issues) so what I've started doing is
putting an underscore in front of the ivar name and then naming the
getter and setter without the underscore:
NSObject *_myObject;
@property (nonatomic, retain) NSObject *myObject;

@synthesize myObject = _myObject;

This way you will be sure you are not accessing the ivar directly
unless you mean to do so.

andiih

unread,
Nov 15, 2009, 6:02:02 AM11/15/09
to iPhone Application Development Auditors
I think this approach is OK. I've seen issues reported with apple
reserving _ for method names (I can't find the original reference),
and therefore you accidentally overloading apple's methods, but I
think this approach is OK as its the iVars this targets.

Mike Carter

unread,
Nov 16, 2009, 2:55:21 AM11/16/09
to iphone-appd...@googlegroups.com
The only issue you need to consider is that those ivars in your class
that you name differently than your getter/setter methods won't be Key
Value Coding compliant, which may be fine in most cases, but doesn't
follow apple's guidelines, and disables KVO/KVC, which are significant
advantages. If you are concerned about access to your ivars, just use
@private or @protected in the interface definition, or use the
'readonly' attribute with @property (if you go that route as opposed
to manually writing your accesors, which in some cases is necessary).
Remember that by using @property, xcode is building your getter
methods using the name of your ivar anyway. You shouldn't run into any
issues by using this technique.

Sent from my iPhone
> --
>
> You received this message because you are subscribed to the Google
> Groups "iPhone Application Development Auditors" group.
> To post to this group, send email to iphone-appd...@googlegroups.com
> .
> To unsubscribe from this group, send email to iphone-appdev-aud...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/iphone-appdev-auditors?hl=
> .
>
>
Reply all
Reply to author
Forward
Message has been deleted
Message has been deleted
0 new messages