@property NSString* whatsTheProblem?

-retain and -copy do the same thing for immutable strings. You can use either, but using -copy guards you against mutable strings cast to NSString*.

 

If you use copy on an NSString, even if it's really an NSMutableString behind the scenes, you will be guaranteed to get back an immutable NSString. If you only use retain, then you're just referencing the original object, and that object's contents could change, introducing problems with your code.

 

I'm bored at work (but don't tell my boss), so I'll take a stab at an explanation.

There are rhetorical questions littered through the explanation. Try to stop and answer the question before reading on.

As you know retain increments the retain count of an object so that it isn't deallocated while you still hold a pointer to it.

Copy, naturally, copies an object. What's the goals of copying an object instead of just retaining it? The goal is to have an independent copy from the original so that if the original changes, the copy you have doesn't, or vice-versa.

Now think about an immutable class like NSString. If I was implementing the copy method of NSString, I could actually copy the NSString object so that the object exists twice in memory. But what's the point? A NSString object can never change. I can give you a pointer to the same object and you'd be just as happy as with a complete copy. Why? Because the object you have will not change on you, because it can't change. Similarly you can't change the object on someone else, because it can't change.

The only thing I'd need to do is make sure I retain the object before I return it back to you when you call my NSString copy. Why? Because of the Cocoa memory rules. If you call copy, you own the returned object and so are responsible for calling release. I need to ensure your call to release doesn't deallocate the object if there are other co-owners. So I match the expected future release with a retain.

That is why retain and copy do the same thing for NSString. It's an optimization.


Now think about creating your own class that has an NSString* ivar or property. You can assume an NSString is immutable and it won't change, right, because NSString is immutable? So you could do something like cache the length of the string into another ivar, right?

Well, not always. When is an NSString* not immutable? When the pointer is actually to an NSMutableString object.

If I used your class described above and set the property to a NSMutableString it would work because NSMutableString is subclass of NSString. By way of the substitution principle of OOP, I can assign a pointer to a subclass object to a pointer to a superclass type. Your class would go ahead and cache the length of the string I gave you. But I would break your class if I changed that NSMutableString; perhaps innocently, perhaps deliberately.

How can you guard against this? How can you be sure you actually have an NSString and not an NSMutableString? Make your sure you use a copy property or you call copy when you set the ivar. Don't use retain. By way of convention (not enforcement), when there's an immutable version of a class and a mutable subclass, copy will return an immutable copy.

This is way Steinberg is saying you should use copy and not retain. It's not right that you can't use retain. It's just that you better off in terms of robustness to use copy.

 

Suppose "someone" using your code (probably you, 6 months later, having forgotten not to) passes a mutable string into your object, then continues changing it afterwards. Your object now has this string that, unbeknownst to it, is changing out from under it. Probably not what you wanted.

So, if you -copy it, then if it's mutable, you'll get a nice fresh string that's safe against that problem. If it's *not* mutable, then it's just as fast as if you called -retain.

Given that, why not -copy?

 

Why would you consider it cheating to not do unnecessary work?

There are two separate protocols for copying, NSCopying and NSMutableCopying. The rules for them are:

- If a class has both mutable and immutable subclasses (NSString, NSArray, NSData, etc), it must provide an immutable instance when -copy is called and a mutable instance for -mutableCopy .

- Any class that does not have mutable and immutable subclasses need only adopt NSCopying protocol. And no class with both types us actually required to adopt NSMutableCopying protocol: a designer should only do what is necessary, sensible and practical.

-copy includes an implicit -retain, so no object you copy will ever be released until your code releases it. Once you copy, you own and are responsible for disposal (note that @property does handle release of the old object when you overwrite a pointer, but it does not relieve you of writing a -dealloc method).

 

The runtime environment doesn't have to cheat, cut corners, or do anything special. You're forgetting that it's the object itself that determines what -copy does. It's not a function copy(), it's a method -copy. The difference is crucial.

NSString's -copy can safely and easily be implemented to return a retain'ed self. This works because any NSString implementation surely knows that NSString is immutable. All objects that are NSString's would use this method when -copy is called. No "runtime ISA() test" is needed, because normal object method dispatch suffices.

NSMutableString's -copy implementation is not so lucky. It knows that the returned object is presumed to be immutable, so it must copy and return another object distinct from self. But once again, every NSMutableString will already do this simply by the nature of Objective-C, which is to invoke a method that is appropriate for the object's actual class. So again no "runtime ISA() test" is needed, because normal object method dispatch suffices.

What seems like a big problem is only a problem when you don't have a generalized object-oriented message system; i.e. if you had to implement this in plain ordinary C. But since you do have a generalized object-oriented message system as the foundation of Objective-C, it's quite simple, and you don't have to do anything special at all: it just happens as a natural consequence.

 

fwiw I'd say it's totally cheating. It's just English wording at that point, though, not ObjC wording.

 

I would say there are two reasons it is not "cheating". The first is, why would you populate memory with a bunch of redundant pointers? It would make no sense to build a shadowing mechanism into Cocoa when you can just reuse the existing object by incrementing its retain count. And I would guess that an object like a NSString would malloc a memory block for its string data, so you cannot just make a new string object that uses the same memory block, because how do you know when the last copy of the string has been released and it is safe to free the underlying block?

You are suggesting that needless complexity is the alternative to "cheating", because you might want different pointers for your "copies", for comparison purposes I guess. Most programmers will write code that does not spit up if a copy of an object is actually the same object, and this is the audience that Apple is writing for.

I do not like to do more work than I feel I need to, but sometimes that is what the task required. Just today, I learned that you can initialize a NSDictionary by reading a .strings file into it, but I had so hoped that the objects array would fill in the sequential order of the file, or something like it. Alas, no such luck, I was forced to write a little extra code to get exactly what I wanted. And that is how programming is. Sometimes you can "cheat" and get a good, consistent result, sometimes you just have to bite the bullet and churn out a few more lines of code or create a new class.

 

I didn't say cheating was a bad thing.