FROM : Sherm Pendley
DATE : Wed Nov 20 05:49:52 2002
On Tuesday, November 19, 2002, at 10:13 AM, Starman wrote:
> So, I understand that a copy of a NSString gives me a new instance of
> the object. But in fact, I get the same object (same memory address),
> with retainCount incremented by one.
>
> I think it could be something optimized
Precisely - it's an optimization.
The purpose of making a copy is to have a new, independent instance,
where changes made to the original after the copy operation won't be
reflected in the copy, and vice versa. But an instance of NSString is by
definition immutable; there can *never* be any changes made to the
original, nor can any changes be made to the copy. So, there's nothing
to be gained by actually making a true copy.
This is specifically allowed for in the description of the NSCopying
protocol. In the section that begins with "Your options for implementing
this protocol are as follows," the last option is:
Implement NSCopying by retaining the original instead of creating a
new copy when the class and its contents are immutable.
> , since you gain memory space and computing time, but can we say that
> NSString conforms to NSCopying Protocol ? It has not the behaviour a
> developer will expect....
Yes, but the difference is academic - I can't think of any real-world
circumstances where it would actually matter. The only reason it could
possibly matter would be if your intent was to modify either the
original or the copy. In the first case, the original would be an
NSMutableString to begin with, and that class' copy: method behaves as
expected. In the second case, what you want is not a duplicate of the
original; it is similar to the original, but mutable and of a different
class, so you'd want to obtain the copy by calling mutableCopy, not copy.
sherm--
If you listen to a UNIX shell, can you hear the C?
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
DATE : Wed Nov 20 05:49:52 2002
On Tuesday, November 19, 2002, at 10:13 AM, Starman wrote:
> So, I understand that a copy of a NSString gives me a new instance of
> the object. But in fact, I get the same object (same memory address),
> with retainCount incremented by one.
>
> I think it could be something optimized
Precisely - it's an optimization.
The purpose of making a copy is to have a new, independent instance,
where changes made to the original after the copy operation won't be
reflected in the copy, and vice versa. But an instance of NSString is by
definition immutable; there can *never* be any changes made to the
original, nor can any changes be made to the copy. So, there's nothing
to be gained by actually making a true copy.
This is specifically allowed for in the description of the NSCopying
protocol. In the section that begins with "Your options for implementing
this protocol are as follows," the last option is:
Implement NSCopying by retaining the original instead of creating a
new copy when the class and its contents are immutable.
> , since you gain memory space and computing time, but can we say that
> NSString conforms to NSCopying Protocol ? It has not the behaviour a
> developer will expect....
Yes, but the difference is academic - I can't think of any real-world
circumstances where it would actually matter. The only reason it could
possibly matter would be if your intent was to modify either the
original or the copy. In the first case, the original would be an
NSMutableString to begin with, and that class' copy: method behaves as
expected. In the second case, what you want is not a duplicate of the
original; it is similar to the original, but mutable and of a different
class, so you'd want to obtain the copy by calling mutableCopy, not copy.
sherm--
If you listen to a UNIX shell, can you hear the C?
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
| Related mails | Author | Date |
|---|---|---|
| Starman | Nov 19, 16:13 | |
| Ondra Cada | Nov 20, 05:19 | |
| Sherm Pendley | Nov 20, 05:49 | |
| Glenn Howes | Nov 20, 07:28 | |
| Jonathan E. Jackel | Nov 20, 23:28 | |
| Finlay Dobbie | Nov 23, 23:43 |






Cocoa mail archive

