Does Objective-C use short-circuit evaluation?

Objective-C does support short-circuit evaluation, just like C It seems that in your example myString is NSNull and not nil therefore myString! = nil is true NSNull is a singleton and is used to represent nil where only objects are allowed, for example in an NSArray Btw, normally, people write if (!myString && myString. Length == 0) Comparing to nil is quite ugly.

Also, I'd compare the length to 0. That seems to be more clear.

Thanks for the tip. Im still trying to align myself with all the syntax & naming conventions. – ifwdev Jan 13 '10 at 22:35 2 I wouldn't say people 'normally' don't compare to nil.

I've seen it done both ways with equal frequency. The argument being that you can read it as 'if myString is not nil' as opposed to 'if not myString'. – bobDevil Jan 14 '10 at 1:23 Actually you're incorrect comparing to nil via (nil == variable) is the correct way to insure that a message is not send to a nil object.

– Inturbidus Oct 27 at 20:54 @Inturbidus: I'm not sure I understood what you meant. If you think one should use if (nil == myString) instead of if (!myString) you're wrong. Nil is defined as 0 and therefore the two comparisons are exactly the same.

– Georg Schölly Oct 28 at 7:47.

Objective-C is a strict superset of C. Because C supports short-circuit evaluation, Objective-C does as well.

If it is an object that is supposed to represent nothing, than it would not be nil. In other words, NSNull and nil aren't the same.

If you have an NSNull somewhere, you are probably either using a JSON parser or CoreData. When a number in CoreData is not set, CoreData will give you back NSNull - possibly the same goes for NSString values in CoreData too. Similarly, you can have empty elements in JSON returned from a server and some parsers will give you that as an NSNull object.So in both cases, you have to be careful when you are using values since the thing you thought was an NSString or NSNumber object is really NSNull.

One solution is to define a category on NSNull that simply ignores all non-understood messages sent to the object, as per the code below. Then the code you have would work because NSNull. Length would return 0.

You can include something like this in your project . Pch file, which gets included in every single file in your project. // NSNull+IgnoreMessages.

H @interface NSNull(IgnoreMessages) - (void)forwardInvocation:(NSInvocation *)anInvocation; - (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector; @end //NSNull+IgnoreMessages. M #import "NSNull+IgnoreMessages. H" @implementation NSNull(IgnoreMessages) - (void)forwardInvocation:(NSInvocation *)anInvocation { if ( self respondsToSelector:anInvocation selector ) anInvocation invokeWithTarget:self; } - (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector { NSMethodSignature *sig=NSNull class instanceMethodSignatureForSelector:aSelector; // Just return some meaningless signature if(sig==nil) sig=NSMethodSignature signatureWithObjCTypes:"@^v^c"; return sig; } @end.

That's just waiting to fail. It's important to know when you're dealing with NSNull instead of nil, your code makes that less likely to happen. In the question's example there's an error message containing NSNull, you wouldn't see that with your code and if (myString) would still evaluate to true.

– Georg Schölly Jan 14 '10 at 11:09 So tell me how can it fail if you can send any message to it, just like nil... and it will still call through to any message actually understood by NSNull (including all NSObject methods). Now it can cause bugs, in that if you check expressly for equivalence to nil that will not be true. But in most coding, exactly because nil can be sent any message I just test against something like ( myString.

Length > 0 ) which works fine here. Indeed, this code will PREVENT possible crashes in your code when an NSNull slips in where you did not expect it, so on the balance it is a stability gain. – Kendall Helmstetter Gelner Jan 14 '10 at 15:41 Also, where does it say is an error message?

That doesn't even make any sense, why would anything wanting to send back an error message ever send NSNull in place of a NSString? In practice I have only ever seen NSNull coming out of CoreData and some JSON Parsers, in ways where this test does nothing except prevent non-obvious runtime errors. You can still check for NSNull where important.

– Kendall Helmstetter Gelner Jan 14 '10 at 15:45 The error message is mentioned in the question: -NSNull length: unrecognized selector sent to instance. I think it's extremely dangerous to say that your technique prevents crashes. Those crashes would only exist because the programmer didn't see that NSNull gets returned.

This is a perfect example of masking bugs. And in this case, it could lead to data loss if there is some logic doing something with NSNull. – Georg Schölly Jan 14 '10 at 21:59 why not just NSMethodSignature *sig=self methodSignatureForSelector:aSelector; – user102008 Jul 30 at 1:21.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.