A potential direction for Objective-C

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 @== and @!= 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 @"" does.

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.

3 thoughts on “A potential direction for Objective-C

  1. Martin Pilkington

    This sounds like a pretty good idea. The thing is, Objective-C isn’t really getting any bigger. We haven’t had many new features in the language in the past 10 years. Real exceptions, blocks, ARC, GC, class extensions, ivars in .m files, improved protocols are the only ones I can really think of. Everything else including properties, dot syntax, fast enumeration, collection/number literal syntax etc are just providing a simpler syntax for common patterns or API calls.

    However, any syntactic sugar should only be added for VERY common operations. For most things the verbosity of Obj-C is incredibly useful, but for creating arrays, numbers, properties or testing equality it gets in the way. I think the @ sign is a great way for Obj-C to gain nicer syntax for these features without the need to overload C operators.

    I would maybe suggest one additional area to add syntactic sugar:

    NSString *myConcatinatedString = myString @+ myOtherString;

    Concatenating string literals is easy enough but for strings in variables, it could be quite useful and save many -stringByAppendingString: calls. Of course the potential issue is that people may expect it to work like other languages where you can also insert scalars (for objects it could be got around by calling -description on each object).

  2. Michael Robinson

    I agree: @== would help shrink my code, which is a good thing. And yes, using === would likely result in more confusion. One could add notes for correct usage of @== & @!= next to the relevant functions in the docs, i.e. next to isEqualToString:.

    Martin’s suggestion:
    NSString *myConcatenatedString = myString @+ myOtherString;

    Is equally valid in my opinion.

  3. Ole Begemann

    One problem I see is the behavior when the “operators” are nil. Assuming obj is nil, [obj isEqual:nil] returns NO because all messages to nil return 0. Consequently, (obj @== nil) would have to return NO, too, which could be even more confusing.


Leave a Reply

Your email address will not be published.