tags:

views:

1162

answers:

3

In Objective-C, what's the difference between declaring a variable id versus declaring it NSObject *?

+15  A: 

With a variable typed id, you can send it any known message and the compiler will not complain. With a variable typed NSObject *, you can only send it messages declared by NSObject (not methods of any subclass) or else it will generate a warning. In general, id is what you want.

Further explanation: All objects are essentially of type id. The point of declaring a static type is to tell the compiler, "Assume that this object is a member of this class." So if you send it a message that the class doesn't declare, the compiler can tell you, "Wait, that object isn't supposed to get that message!" Also, if two classes have methods with the same name but different signatures (that is, argument or return types), it can guess which method you mean by the class you've declared for the variable. If it's declared as id, the compiler will just throw its hands up and tell you, "OK, I don't have enough information here. I'm picking a method signature at random." (This generally won't be helped by declaring NSObject*, though. Usually the conflict is between two more specific classes.)

Chuck
Great explanation, though I hesitate to say that "In general, id is what you want". Although "id" is quite flexible due to the dynamic typing, it also provides virtually no warnings, so if you call an unsupported method, what could be caught at compile time becomes a runtime problem. Static typing (with MyClassName* etc.) when used judiciously can make life much simpler, particularly when debugging in Xcode (it can show a more intelligent summary of the object) or catching method calls with misspelled or incomplete selectors.
Quinn Taylor
The distinction I meant to draw is specifically between id and NSObject*, not static typing in general. It's much more common that you'd want to use id than statically type as NSObject.
Chuck
+7  A: 

id means "an object", NSObject * means "an instance of NSObject or one of its subclasses". There are objects in Objective-C which are not NSObjects (the ones you'll meet in Cocoa at the moment are NSProxy, Protocol and Class). If some code expects an object of a particular class, declaring that helps the compiler check that you're using it properly. If you really can take "any object" - for instance you are declaring a delegate and will test all method sends with respondsToSelector: calls - you can use an id.

Another way to declare an object variable is like "id <NSObject>", which means "any object which implements the NSObject protocol.

Graham Lee
+1  A: 

From my limited understanding of Objective-C, not all objects are derived from NSObject (unlike Java where all objects derive from Object). You can theoretically have other root objects. id could apply to any of those non-NSObject derived objects.

Julien Chastang