Why use id when we can just use NSObject?

Question

I know that when we want to create an unknown value object we use id. However, I'm curious that why did Apple to choose id which decides it's value during runtime, when every object is a subclass of NSObject. So instead of id delegate we could have used NSObject *delegate Does anyone know why? Thanks.

Answer 1

id erases the type and it is equivalent to saying "this object responds to any selector visible to the translation". Of course, it is your responsibility to make sure your program is correct when you erase types (and also when you typecast them).

If the type were NSObject, then the compiler would say "NSObject may not respond to selector" if the selector was not declared in NSObject's interface or the protocols it adopts. In that event, you could also add a typecast to cast it to the type you expect.

With strict/correct types, the compiler can kick in and help you out, which is great because ObjC is a very dynamic language.

id is particularly useful when using (or building) collections types. Adding an object would not be a problem unless you defined a new root type (does not inherit from NSObject). Getting a value from the collection would require a typecast if we were to use it as something other than our base class (NSObject).

Objective-C does not support generics - you cannot, for example, declare an NSArray of NSStrings. You can populate an NSArray with NSStrings and pass this through id for a more natural written style when type safety is not preserved (a la generics).

So, let's expand on this with some real code.

Example A

NSString * string = [array objectAtIndex:0]; // << trust me (via id) return [string length]; -or- return [[array objectAtIndex:0] length]; // << trust me (via id) 

Example B

And now let's say id is not available and we fix all our compiler warnings because it's the right thing to do:

NSString * string  = (NSString*)[array objectAtIndex:0]; // << typecast == trust me return [string length]; -or- return [(NSString*)[array objectAtIndex:0] length]; // << typecast == trust me 

id doesn't decide its value at runtime, nor does any NSObject. ObjC objects don't perform implicit promotions, they just cast the pointer through without formal promotion.

Related to your example, I actually declare my delegates and parameters as NSObjects with protocols:

NSObject<MONShapeDelegate>* delegate;