Re: Best Way to Handle Properties?
Re: Best Way to Handle Properties?
- Subject: Re: Best Way to Handle Properties?
- From: Dave <email@hidden>
- Date: Thu, 21 Aug 2008 09:03:35 +0100
On 20 Aug 2008, at 19:37, Ken Thomases wrote:
On Aug 20, 2008, at 12:42 PM, Dave wrote:
On Aug 20, 2008, at 6:05 AM, Dave wrote:
-(void) setFirstName:(NSString*)theNewValue
{
if (FirstName != theNewValue)
FirstName = [theNewValue copy];
}
The reason I did it like this in that case is that I copied and
pasted one template for all 56 odd properties, I didn't want to
have to edit them all again later on.
If you really have 56-odd setters all implemented in the same way,
you have a big problem. That implementation is simply not viable.
It doesn't do proper memory management. Think of what happens if
you call it twice over the lifetime of the PersonDetails object.
The first time perhaps you are "lucky" and FirstName is nil. In
that case, there isn't an old string that needs to be released
before you change the FirstName ivar to point to the new copy.
However, on the second time through, FirstName holds a pointer to a
string object which this PersonDetails object owns. Before it
loses that pointer (by replacing it with a new pointer) it needs to
release that old string. So, the expected form of the setter would
be:
- (void) setFirstName:(NSString*)theNewValue
{
if (firstName != theNewValue)
{
[firstName release]; // This is the important thing you're missing
firstName = [theNewValue copy];
}
}
However, if you have accessors (like these examples) which don't do
any custom processing (like modifying the new value), then your
best bet is to let the compiler synthesize them. You're allowed to
synthesize some properties' accessors while manually implementing
others (those that require custom behavior).
No, not all 56 like that, only so many are strings, and I've not
finished yet, I'll have to edit them all again anyway I know, but I
didn't know that when I originally wrote it!
The copy operation here, copies that data from one string to a
newly allocated string, right?
Conceptually, yes. The copy message gives you back a new string
which is a copy of the string to which you sent the message.
There is a wrinkle. As an optimization, when you copy immutable
value objects you may actually just receive the same object back,
with its retain count incremented. That is, for those kinds of
objects, -copy may be a synonym for -retain. This is OK because
two copies of the same immutable value behave exactly the same, so
there might as well be only one. You don't have to worry about
this optimization; it's an implementation detail. I just wanted to
make you aware of it because you specifically asked if you get a
newly allocated string, and sometimes you don't, but in those cases
it doesn't matter. :)
Because both -copy and -retain leave you with the same ownership
responsibility, there is no memory management implication from this
optimization, either.
Ahhhh, ok, now I'm beginning to understand. I hadn't seen the Memory
Guidelines Manual before, I've read it one and am just about to do so
again.
Are all 56 properties required for the object to be valid? I
wasn't suggesting that you not use setters after the object is
initialized. I was suggesting that initializing an object should
result in a valid object.
Yes, all 56 properties are required for the object to be valid
Yikes.
so in the initializer I set the NSString pointers to nil, zeroize
the integers and set the dataValid flag to FALSE.
Just so you know, the Objective-C runtime guarantees that +alloc
(or +allocWithZone:) gives you an object with all of its ivars
zeroed out. So, there's no need for you to manually do that.
All the Best
Dave
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden