What is preferable in objective-c: id or explicit type?

What is better and why ?开发者_如何学Go

What is better in such situations as the class init method and usual variables in a code ?

What is better and why ?

Explicit typing information is always better unless you just can't use it for some reason (see below).

It allows the compiler to much more stringently validate the code and will catch many errors at compile time that would otherwise cause your app to crash at runtime.

A long, long, time ago, everything in the APIs used id. This proved to be a complete pain in the butt; fragile and led to many crashes that would have been caught with specific types.

So, it was changed. (This was ~1994).

What is better in such situations as the class init method and usual variables in a code ?

For init, you have no choice but to use the generic (id) return type. Objective-C does not support either co-variant or contra-variant declarations, nor is there a mechanism for generalizing the declaration of init while also providing support for specific type checking.

Same goes for retain, objectAtIndex:, addObject: and many other methods that take or return one of many kinds of objects (or take 'em as arguments).

And, no, there is absolutely no performance difference whatsoever between id and, say, NSView*.

can you give an example when explicit typing will cause a problem please?

If you wrote:

- (MyClass *) init;

And in a subclass:

- (MySubclass *) init;

You'd get compiler warnings out the wazoo most likely or you'd have to typecast out the wazoo.

On recent versions of clang (in Lion) you should actually not return id, and instead return instancetype. This is a keyword that is used in return types to specify that the type it returns is an instance of the class receiving the message. It is now the preferred return type for init methods on OS X Lion.

Explicit typing provides build-time protection, informing you of likely problems if you do things such as casting or performing operations on something that probably won't work.

Explicit typing also helps prevent non-obvious transfer of mistyped objects, something traveling through a path in your code you hadn't considered that turns out to be of an unexpected type. This kind of bug often doesn't become clear until the program has been tested a lot, more commonly after its release.

It's also helpful for future programmers (including your future self) trying to work with your code, making to more likely that they'll be able to tell at glance what an object is supposed to be. It makes code more "self-documenting" as a result.

Some things cannot have a meaningful type because no type actually applies. Other times you need to use id because you need to be able to accept any type of object. Cocoa Touch uses it, for example, when referring to the sender of a message because anything could have sent it; specifying an explicit type simply wouldn't work.

The vast majority of the time, though, an explicit type is to your advantage.

Use a type as specific as you can but not more so. Consider how you are using any particular variable, argument, or return type and set its type appropriately.

For example a UITableView's dataSource property is declared as id<UITableViewDataSource> because the table view only cares that its data source is some object which conforms to the UITableViewDataSource protocol. This allows the data source to be flexible enough for use with any specific class which implements the protocol but still allows the compiler to warn you if you attempt to assign an object which does not implement that protocol as the data source.

If you are too specific then your code becomes inflexible, accepting only specific implementations which are not strictly necessary (ie demanding a NSMutableString when you could really work with any NSString).

If you are too vague (typing everything as id for example) then you lose the ability to identify when you are sending unrecognized selectors to a particular instance and the compiler cannot identify any number of invalid statements.

For init methods follow the advice in The Objective-C Programming Language

The return type of an initializer method should be id.

The reason for this is that id gives an indication that the class is purposefully not considered—that the class is unspecified and subject to change, depending on context of invocation. For example, NSString provides a method initWithFormat:. When sent to an instance of NSMutableString (a subclass of NSString), however, the message returns an instance of NSMutableString, not NSString. (See also, though, the singleton example given in “Combining Allocation and Initialization.”)

I don't think there is a performance difference between both. You can let id return type for init because you can cast the result of your init.

For exemple :

Toto *foo = [[Toto alloc] init];
id foo2 = [[Toto alloc] init]; 

Both work but you'll have to cast foo2 variable like that (Toto *)foo in order to access property or methods of your instance without creating a compiler warning. Even if it works fine...

I think some developers let id because they just pass there variable trough instance and don't use it. That kind of use allow to not import the .h

Regards,
KL94