As with my Xcode rant, this is a modified version of a mail I sent to an Apple mailing list, in this case objc-language:
I agree that adding an === operator to Objective-C would be, at the very best, questionable at this late date, if indeed it was ever anything else. My experience in PHP has been that the two are very often confused and misused, and I can’t see that being any different in Objective-C.
I do strongly support the concept of
@!= operators that equate to
[object isEqual:] and its negation, as well as the associated
@> etc. operators. If one of the objects in question can be determined not to implement compare:, throw a compile error. If either operand is typed
id, throw a runtime exception, exactly as
[(id)[[NSObject alloc] init] compare:] would do now. In short, make the operators mere syntactic sugar, just like dot-syntax and the collection literals, rather than trying to toy with the runtime as
This is not “arbitrary” operator overloading, as with C++. That would be an absolutely abhorrent idea, IMO. Define new, unambiguous operators and make it very clear exactly what happens when they’re used. Don’t make it possible to change that behavior from affected code. Add a compiler option or ten so you can do
-fobjc-compare-selector='myCompare:' or what have you (as with the one for the class of constant strings), but that’s all.
I understand people who complain that Objective-C is getting “too big”, but the fact that the collection literals were implemented (yay!) makes it clear, as far as I’m concerned, that it’s understood that the language is just too verbose (and difficult to read) as it stands. Adding a new set of clear, intuitive operators would not detract from its usability. People who don’t know enough to write
@== instead of
== were already going to write
== instead of
isEqual: anyway, as a rule.