CODEWITHSUNDEEP
objective-c
Echelon
Echelon

Reputation: 7922

Will it always be safe to use "id" as a method name in an Objective-C protocol?

On a client codebase I'm working on, someone has named a method in a protocol like so:-


- (NSString *)id;

I know it compiles fine, and I know it's not a reserved word in Objective-C (as discussed here), but still I'm slightly uneasy with this. Apart from aesthetic issues, I'm specifically worried about future-proofing: is this guaranteed to always be legal Objective-C?

I have to use the protocol, and I don't know if it's worth changing it across the board (and the conversations with the client about why I'm doing that).

Upvotes: 0

Views: 54

Answers (1)

zxq9
zxq9

Reputation: 13164

No. In particular, it is probably always going to be legal Objective-C, but the label "id" itself is a lot like the label "test": it is unwise to use it because it is almost guaranteed to clash with something else in the environment eventually. Your language is Objective-C, but any frameworks, imports, class extensions, etc. are almost bound to eventually involve something else called "id" later on down the road.

It can be irritating to track down a bug that results from, for example, deciding to port existing code to use some helpful framework, only to discover the either your "id" is overriding a value the framework expects, or that the framework/mixin/subclass/whatever is overriding or otherwise redefining it and you weren't aware.

I steer clear of what I consider universally overloaded labels like "doc", "test", "id", and "init" (when not already reserved in langX) in every language and environment I encounter. It seems that the use of any of these terms always ends in grief. (The grief of a massive search/replace, which isn't always as easy as simple text replacement in the code).

Upvotes: 1

Related Questions