macOS Kochan 2.0: Question about synthesized accessors ( exercise 15.9...mainly)

[mdeh]

May I ask a few questions relating to this exercise.

1) How would one store an instance variable like "playtime". As an NSString* ( eg "@1 hr 32 mins"?) or perhaps as a number object?

2) We have been taught, up to now ( not yet at GC) how to release, for example, an addressCard with instance variables that have alloced memory.

So, for instance, given a card with a single NSString *name ( for example) the dealloc method would be something like:

-(void) dealloc
{
[ theProperty release];
[super dealloc];

and the setter would be *something* like

-(void) setProp: (NSString *) aProp
{
[theProperty release];
the Property = [ [ class alloc] initWithProp: aProp];

etc etc.

Now, using synthesized methods:

@property ( copy, nonatomic) NSString *theProperty

I **think** that the above will do the same as the release and assign ( with new alloc) in the above code. But what about the release during the "dealloc" method. Will it take care of that?
The reason I ask, is that the documentation says:

Although this works well for strings, it may present a problem if the attribute is a collection such as an array or a set. Typically you want such collections to be mutable, but the copy method returns an immutable version of the collection. In this situation, you have to provide your own implementation of the setter method, as illustrated in the following example.

If I have not articulated my exact issue, it is that I do not clearly understand it yet myself. Any insight is appreciated

 

[gnasher729]

May I ask a few questions relating to this exercise.

1) How would one store an instance variable like "playtime". As an NSString* ( eg "@1 hr 32 mins"?) or perhaps as a number object?

Why would you use anything other than a double?

 

[lee1210]

Why would you use anything other than a double?

Or an int/long int if sub-second precision is not needed.

-Lee

 

[mdeh]

Or an int/long int if sub-second precision is not needed.

-Lee

Thanks Lee.
But that was almost a side question to the main issue.
Thanks again.

 

[eddietr]

I **think** that the above will do the same as the release and assign ( with new alloc) in the above code. But what about the release during the "dealloc" method. Will it take care of that?

No, it will not take care of deallocation for you. Synthesizing a property really just creates the property and setProperty: methods for you.

If setter that is created (or that you write yourself) does a copy or retain, then you would need to release the object yourself in - dealloc.

 

[mdeh]

If setter that is created (or that you write yourself) does a copy or retain, then you would need to release the object yourself in - dealloc.

Eddie...thank you. So, it's nothing more than getter and setter methods!! ...synthesized!! DUH!

Another quick question. The issue of "nonatomic". Is there a simple explanation - I know it is coming up in a couple of chapters...or is it something that requires an in depth look at. ( For instance, the documentation says:

If you specify nonatomic, then a synthesized accessor for an object property simply returns the value directly.

It also says some other seemlngly contradictory stuff, but if you think it is too detailed, I will wait.

 

[eddietr]

Another quick question. The issue of "nonatomic". Is there a simple explanation - I know it is coming up in a couple of chapters...or is it something that requires an in depth look at.

So in a nutshell, "atomic" (which, btw is the default) means that the getters and setters that are generated are written so that they are thread safe. Meaning that multiple threads can be getting and setting your property and they will not get incomplete results.

If you know only one thread will be calling these getters and setters, or if your application has some other mechanism already to deal with multiple threads accessing these particular objects, then you probably don't want the overhead of thread-safe getters and setters. So in those cases you have the ability to declare a property nonatomic.

And so the getters and setters are smaller, simpler and faster because they don't need to worry about the thread safety issues.

Hope that makes sense?

 

[mdeh]

Hope that makes sense?

yes it does...thanks.

 

[gnasher729]

So in a nutshell, "atomic" (which, btw is the default) means that the getters and setters that are generated are written so that they are thread safe. Meaning that multiple threads can be getting and setting your property and they will not get incomplete results.

If you know only one thread will be calling these getters and setters, or if your application has some other mechanism already to deal with multiple threads accessing these particular objects, then you probably don't want the overhead of thread-safe getters and setters. So in those cases you have the ability to declare a property nonatomic.

And so the getters and setters are smaller, simpler and faster because they don't need to worry about the thread safety issues.

Hope that makes sense?

Setter and getter functions are thread safe in the sense that if two threads call the setter function simultaneously, for example, then all your retain counts will be ok afterwards; the two setters will run one after the other and their code will not be mixed together with likely bad results. Still, the value stored by one of the setters will be lost, so you would still have to check your program logic carefully in a multi-threaded system.

 

[mdeh]

Setter and getter functions are thread safe in the sense that if two threads call the setter function simultaneously, for example, then all your retain counts will be ok afterwards; the two setters will run one after the other and their code will not be mixed together with likely bad results. Still, the value stored by one of the setters will be lost, so you would still have to check your program logic carefully in a multi-threaded system.

Thanks gnasher