Re: Empty NSStrings, nil NSStrings
Re: Empty NSStrings, nil NSStrings
- Subject: Re: Empty NSStrings, nil NSStrings
- From: j o a r <email@hidden>
- Date: Sun, 16 Apr 2006 20:02:41 +0200
On 16 apr 2006, at 18.35, Ondra Cada wrote:
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.
Agreed, that's a better example.
str=[str?:@"" stringByAppendingString:@"whatever"]
Obfuscation...
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.
Just keep the following in mind:
<http://developer.apple.com/documentation/MacOSX/Conceptual/
universal_binary/universal_binary_tips/chapter_5_section_22.html>
On 16 apr 2006, at 19.41, Rosyna wrote:
Sometimes the fact they aren't interchangeable causes bugs. For
example, two separate bugs in Font Book are caused because it
always assumes a string will be either NULL or have a length>0. But
in these two completely separate cases, it gets an empty string,
tries to call -characterAtIndex:0, and throws an exception.
It's a very common mistake when using the string returned from -
[NSEvent characters] or -[NSEvent charactersIgnoringModifiers]! Note
to developers: Check your code!
j o a r
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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