Sending Messages to nil....

M

macxonly

Registered
Help! Newbie warning...

I am currently reading Aaron Hillegass' book, and am confused on page 42.

The code reads:

id foo;
foo=nil;
[foo count];


Can somebody explain what each line of the code does, and possibly explain why I "should be happy" about this. (I understand the Java code before this example, so no help needed there) Thanks all it will be greatly appreciated!
 
id foo;
declares an object named foo.

foo=nil;
sets foo's value to nil/null.

[foo count];
returns foo's count. should be zero. if you had an array, the count method would be useful to get the number of elements in your array.
 
To be pedantic:

Code: 
id foo;

Declares a variable of type id, which is an unspecified Obj-C type, much like void * in C. So you can have foo reference any Obj-C object you create.

Code: 
foo=nil;

foo now points to nothing. So if you try to send a message to it, where does the message go? To nothingness.

If you try to send a message to foo before pointing it to something (even nothingness!), then your app will die and crash painfully.

Code: 
[foo count]

Obj-C allows you to send messages to objects that may or may not respond to them. Java, on the othere hand, cries like a baby because it's strongly typed. Because NSDictionary and NSArray have methods called count, the Obj-C runtime knows that sending the message count to an object (not that we know which one) is okay. It's up to the user to make sure that foo points to an object that actually implements that function. Errors will be reported at runtime instead of at compile time (like in Java). If foo was actually declared to be of some type other than one that implements count, then you would receive an error at compile time.

In Java, you can't call functions off of nothing (which kind of makes sense), but in Obj-C you can get away with it (messaging to nothing). I would actually prefer to know if I'm sending messages to nil, but I'll live. In Java, your app would probably crash or begin to behave strangely, but in Obj-C it's a normal thing.

Just for the record,
F-bacher
 
One more quick note: According to Apple's Objective-C language reference, you can safely send a message to a nil object provided that the message returns an object. The returned object will always be nil. However, if the return value is not an object, the return value is undefined. So, you could safely do something like
Code: 
NSArray *myArray = nil;
id lastObject = [myArray lastObject];
// lastObject is now set to nil

but you could not safely do something like
Code: 
NSArray *myArray = nil;
int objectCount = [myArray count];
// objectCount is now undefined
 
Actually, I just found some code where I did:

Code: 
     int num = [some_random_object count];

And some_random_object was nil! I think it just converted nil to 0.

F-bacher
 
Originally posted by Ghoser777
Actually, I just found some code where I did:

Code: 
     int num = [some_random_object count];

And some_random_object was nil! I think it just converted nil to 0.

F-bacher
Click to expand...
Probably because nil is implemented using a bit pattern of all zeros (which makes sense, since testing for value of zero is inherently faster than testing for any other specific value)

BTW, I do not know how is nil actually implemented.
 
You must log in or register to reply here.
Back
Top