Re: Empty NSStrings, nil NSStrings
Re: Empty NSStrings, nil NSStrings
- Subject: Re: Empty NSStrings, nil NSStrings
- From: Ondra Cada <email@hidden>
- Date: Sun, 16 Apr 2006 18:35:27 +0200
Paolo,
On 16.4.2006, at 13:59, j o a r wrote:
From a "Cocoa" point of view a nil NSString and an empty NSString
(a valid NSString instance containing 0 characters) can/should be
considered interchangeable?
They're not at all interchangeable. A nil value is not a string at
all. Think of nil as another word for "nothing" - It's not an
object at all. An empty string is a string that doesn't have any
characters, but it's still an object, and it can respond to methods
That's very true.
(for example [str length]).
That's not the best example though, for in this *special* case nil
and empty string happen to be iterchangeable indeed. Both [@""
length] and [nil length] give exactly the same result (which is the
documented and right behaviour, often used in code, like "if ([str
length]==0) do something for non-existing or empty string both" --
more on that below).
A better example would be
str=[str stringByAppendingString:@"whatever"]
or perhaps
[dictionary setObject:str forKey:@"some key"]
which give very different results for nils and for empty strings in str.
Therefore, the right answer is: although there is a number of cases
where nils and empty strings are interchangeable, generally they are
not.
Or should I check every NSString and, if nil, turn it into an
empty NSString before working with it (messaging or passing as
parameter)?
Depends on what you are doing with them. Sometimes you don't need to
([str length], or [str release], see below), sometimes you have to.
Like, for example
str=[str?:@"" stringByAppendingString:@"whatever"]
1) About sending messages to nil
You can't send messages to nil, well, you can - but they will
really be ignored by the runtime.
Right. Also worth mentioning they would always return a nil
(regardless the method send).
It doesn't make sense to send messages to "nothing". Sending a
message to an object is like talking to it. If there is no object
to talk to, it's like you're talking to yourself - not much use in
doing that.
Quite the contrary -- very much use in doing that, keeping on mind of
course that you are "shouting into a black hole", and the result
therefore would be (literally) zero, in other words, a nil.
One very common and convenient case is the aforementioned test [str
length] -- the two following lines are completely equivalent, but the
latter is slightly more efficient (which is unimportant), and
considerably more readable (which is extremely important, namely
considering the cost of code maintenance and upgrading):
if (str==nil || [str length]==0) ... // the "Java way" :)
if ([str length]==0) ... // the Objective C way
Some very purists may argue it is, after all, just a custom that nil
and integer zero are the same. Right, but it is one custom which
cannot be broken, ever -- or else some 50-odd per cent of all code
would immediately break, whilst the remaining half would become
unstable. For this very reason, free interchanging of integer zero
and nil (and NULL) is completely safe. (Just to warn, this does *not*
apply for floats -- for example, "float w=[nil widthOfString:@"foo"]"
is an error and may return just anything.)
Even more often this is used in accessing objects which may or may
not exist:
-(void)setFoo:foo {
[myFoo autorelease]; // right even if myFoo is nil, thanks to the
fact [nil anything] is valid and empty operation
myFoo=[foo retain]; // right even if foo is nil, thanks to the
above AND to the fact [nil anything] returns nil
}
2) About sending a nil value as a parameter to other methods
You can send nil instead of objects to methods, but how they will
respond differs between methods. In some cases it has a meaning and
it will work OK, in other cases it is treated as an error, and you
might get an exception.
In other cases it is considered all right, but the semantics will
differ from using an empty string.
You have to check the documentation for each case.
*Absolutely*.
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden