OOP and Foundation 2: Mutability. Detail of declared return type
OOP and Foundation 2: Mutability. Detail of declared return type
- Subject: OOP and Foundation 2: Mutability. Detail of declared return type
- From: Michael Gersten <email@hidden>
- Date: Mon, 10 Jun 2002 13:31:27 -0700
Second point:
>
[ A discussion of copy vs. retain on the output from a library; use 'copy' if you must ensure that it won't be changed underneath you if you must have a non-mutable version.
>
Bill emphasizes that you should only be concerned with the declared return type, not the actual return type.]
I have learned that, in general, you declare your methods to return the most specific thing you can guarantee, and to take on input the least general thing you can accept.
The details:
Now, the discussion of NSString/NSMutableString and the missing NSNonmutableString:
>
[ Bill points out that if you need to keep a string returned from a library call around for a while, and you need to make sure that it isn't changed on you, then you use 'copy' instead of 'retain' to hold it. It's almost a no-op on non-mutables (the implementation in NSString just calls retain), and it tells mutables to make a fresh copy from the non-mutable version.
>
>
He then mentions that you should only rely on the declared return type of the function, not concerned with the real type -- if something is declared non-mutable, but produced iteratively by altering a mutable, then treat it as non-mutable.]
>
I have learned that, in general, you declare you methods to return the most specific thing you can guarantee, and to take on input the least general thing you can accept.
Yes, there are times when I declare a return less specific than actual. But it's rare, and often I'll find I need to declare the real thing anyway.
If a routine needs to build up something over time, and then return it -- the general case of "I'm returning a mutable string because I needed to modify it as I built it", then it should (my opinion) declare that it's returning a mutable string.
Right now, if I want to keep something that I know will not be changed, I need to say 'copy'. This has cost zero for something that couldn't be changed before anyway, and no extra cost for something that can be changed (the cost would have been spent anyway, and cannot be optimized out).
But if I want to keep something and be able to change it, I need to say 'mutableCopy', even if what I was given already was mutable, because it was declared by the library to be just plain.
I can forsee a possible optimization that elimintates this cost: a "mutableVersionCopyIfNeeded" method. Do not make a copy if the object is mutable and the net retain count after autorelease is 0.
--
I am a Mac 10-Cocoa/WOF/EOF developer, and I'm available for hire. Please contact me at michael-job @ stb.nccom.com if interested. Resume at
http://resumes.dice.com/keybounce
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.