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).
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.
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.
Cheers,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
