Re: Returning exactly what has been promised
Re: Returning exactly what has been promised
- Subject: Re: Returning exactly what has been promised
- From: Quincey Morris <email@hidden>
- Date: Tue, 22 Jul 2008 23:12:34 -0700
On Jul 22, 2008, at 21:54, Steve Cronin wrote:
I find if I have a method which returns an NSString for example,
that often, in the interior of that method I will use an
NSMutableString to construct the string I intend to return. My
question concerns the actual final return statement.
Is there ANY reason to choose A over B?
A) return [NSString stringWithString:myWorkingMutableString];
B) return myWorkingMutableString;
It just kinda sticks in my craw me that I 'promised' an NSString and
using (B) I don't return one.
Yeah I do understand inheritance and that a mutable entity
isKindOfClass of the base class
I looking for reasons like edge cases, compiler optimization, error
trapping, portability, etc..
Is there ANY benefit to the costs associated with the explicit
declaration of (A)?
A return value type of NSString* doesn't promise a isMemberOfClass
NSString, just a isKindOfClass NSString (if for no other reason than
there are no isMemberOfClass NSString objects, only private
subclasses). So, returning any NSString subclass is legal.
The only question is whether you're obliged to return an immutable
object, and that seems to be a matter of personal preference (based on
comments on this list when this came up a while ago).
My opinion: If the method doesn't keep a reference to the string it
returns, I don't see any reason why it should not return the mutable
object. If it does, I'd return a copy, for reasons of self-protection,
not for any reasons about what kind of object was promised.
_______________________________________________
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