First question: should age be an int? Or NSNumber? Or NSNumber*? Or NSInteger or NSInteger*? I'm confused about whether NSNumber should be a pointer or not.. after all, it IS an object, and with most of these objects, they're pointers.

Second: is it pretty much a given that the @property option "copy" will be used for NSString* all the time? And "assign" is used for ints and other non-pointers, and "retain" is used for pointers to objects other than NSString? I'm not clear on when to use each one.

That looks fine. It's up to you whether to represent numbers with primitives or NSNumber objects (I don't think there is an NSInteger object class). It's very common to use ints and floats instead of NSNumbers. However, bear in mind that you can only store objects in the collection classes (NSArray, etc.), so if you do that you might find yourself wrapping and unwrapping primitive values to NSNumber anyway, and NSNumbers also work natively with file archiving.

I might also suggest storing "age" as an NSDate containing the person's birthday as well, then you can always derive age from that.

As for copy vs. retain for strings it's up to you but generally strings are copied (unless they are potentially huge because strings can be very large). Copy is a bit safer IMO, then at least you know you own it completely. NSNumbers I would copy as well.

That looks fine. It's up to you whether to represent numbers with primitives or NSNumber objects (I don't think there is an NSInteger object class). It's very common to use ints and floats instead of NSNumbers. However, bear in mind that you can only store objects in the collection classes (NSArray, etc.), so if you do that you might find yourself wrapping and unwrapping primitive values to NSNumber anyway, and NSNumbers also work natively with file archiving.

I might also suggest storing "age" as an NSDate containing the person's birthday as well, then you can always derive age from that.

As for copy vs. retain for strings it's up to you but generally strings are copied (unless they are potentially huge because strings can be very large). Copy is a bit safer IMO, then at least you know you own it completely. NSNumbers I would copy as well.

NSInteger/NSUInteger is a scalar value, so you don't need to represent it with a pointer.

NSNumber allows for 'boxing' values into an object that can be put into NSArrays and the like. It really isn't meant for regular use (performance issues compared to simply using the scalar value in RAM).

NSInteger and NSUInteger is meant to 'mask' the int and long types. NSInteger is guaranteed to be an integer of the same bit-width of the CPU you are running on. NSUInteger is the same, just unsigned. The Cocoa APIs in 10.5 moved to using these definitions so that a 64-bit app doesn't need to be tweaked to compile without any errors or warnings as long as you use these built-in types.

NSInteger/NSUInteger is a scalar value, so you don't need to represent it with a pointer.

NSNumber allows for 'boxing' values into an object that can be put into NSArrays and the like. It really isn't meant for regular use (performance issues compared to simply using the scalar value in RAM).

NSInteger and NSUInteger is meant to 'mask' the int and long types. NSInteger is guaranteed to be an integer of the same bit-width of the CPU you are running on. NSUInteger is the same, just unsigned. The Cocoa APIs in 10.5 moved to using these definitions so that a 64-bit app doesn't need to be tweaked to compile without any errors or warnings as long as you use these built-in types.

Click to expand...

So if I understand this correctly, I really should be using NSInteger instead of int, correct? Just to be on the safe side? Are there other scalar vars like NSFloat? Or can I just use float?

There are a series of int types based on size:
NSInt8, NSInt16, NSInt32, and NSInt64, as well as unsigned varieties.

There is also NSFloat and NSDouble for the single and double-precision floating point.

You don't have to use them, as NSFloat is really just float, and NSDouble is really just double, NSInt8 being char and so on

I like the NSInt<size> ones because it tells me what size the variable is very quickly (and thus its limits). char, short, int, long, long long, etc are a little harder to decipher. For awhile I assumed int would be 64-bit on a 64-bit system, when really long is 64-bit on a 64-bit system.

NSUInteger and NSInteger are there more for the API's sake, and so anything I expect to pass around to the Cocoa API is one of these two, as well as anything where I don't care what the size is. If size is important, I use the NSInt<size> types for ease of reading.

"assign
Specifies that the setter uses simple assignment. This is the default.

If your application uses garbage collection, if you want to use assign for a property whose class adopts the NSCopying protocol you should specify the attribute explicitly rather than simply relying on the defaultotherwise you will get a compiler warning. (This is to reassure the compiler that you really do want to assign the value, even though its copyable.)"

"copy
Specifies that a copy of the object should be used for assignment. (The default is assign.)

The copy is made by invoking the copy method. This attribute is valid only for object types, which must implement the NSCopying protocol. For further discussion, see Copy."

"retain
Specifies that retain should be invoked on the object upon assignment. (The default is assign.)

1) The setter for copy needs to release the old value since -copy increments the retain count

2) All of these only look like that if you also specify nonatomic. Otherwise it'll do some voodoo with locks to make sure that it remains consistent when being used from multiple threads. I think nonatomic is generally what is wanted.

Forget all that, you don't need all that setting, getting and releasing junk in Objective-C 2.0, which is what you're using judging from your property declarations. All you need is this in your header file, as you more or less had:

MacRumors attracts a broad audience
of both consumers and professionals interested in
the latest technologies and products. We also boast an active community focused on
purchasing decisions and technical aspects of the iPhone, iPod, iPad, and Mac platforms.