135

As far as my knowledge, Objective-C does not support method overloading. What can be the alternative for this in Objective-C? Or should I always use different method name?

Pieter
  • 3,339
  • 5
  • 30
  • 63
suse
  • 10,503
  • 23
  • 79
  • 113

3 Answers3

201

Correct, objective-C does not support method overloading, so you have to use different method names.

Note, though, that the "method name" includes the method signature keywords (the parameter names that come before the ":"s), so the following are two different methods, even though they both begin "writeToFile":

-(void) writeToFile:(NSString *)path fromInt:(int)anInt;
-(void) writeToFile:(NSString *)path fromString:(NSString *)aString;

(the names of the two methods are "writeToFile:fromInt:" and "writeToFile:fromString:").

David Gelhar
  • 27,873
  • 3
  • 67
  • 84
  • 5
    @RaheelSadiq It isn't overloading because the method names (In ObjC: 'selectors') are different. Being different, neither one is considered 'overloaded'. If writeToFile:from: were defined twice, with only the parameter *types* being different, then that would be overloading. As stated though, this is not supported in ObjC like it is with other languages including Java and now Swift. – Chris Hatton Nov 06 '15 at 12:57
  • Not just the parameter names themselves, but even the colons are part of the method name, so that -(void) writeToFile:(NSString*)path :(int)anInt; and -(void) writeToFile:(NSString *)path :(NSString*)aString;are also different methods. – Kaiserludi Nov 30 '15 at 11:53
22

It may be worth mentioning that even if Objective-C doesn't support method overloading, Clang + LLVM does support function overloading for C. Although not quite what you're looking for, it could prove useful in some situations (for example, when implementing a slightly hacked (goes against encapsulation) version of the visitor design pattern)

Here's a simple example on how function overloading works:

__attribute__((overloadable)) float area(Circle * this)
{
    return M_PI*this.radius*this.radius;
}

__attribute__((overloadable)) float area(Rectangle * this)
{
    return this.w*this.h;
}

//...
//In your Obj-C methods you can call:
NSLog(@"%f %f", area(rect), area(circle));
Rad'Val
  • 8,895
  • 9
  • 62
  • 92
  • One would think that this hint, combined with method swizzling, could indeed lead to "overloadable" methods... Why one would need to, with `id` and `isKindOfClass:` at ones disposal, though, _is a different story_... – Alex Gray May 04 '14 at 23:25
  • 1
    @alexgray I see your point, `id` and `isKindOfClass:` cover most practical scenarios. One reason you might prefer overloading, is the automatic selection of the most specific type catered for, which would incur a small overhead to maintain with explicit type checking. – Chris Hatton Nov 06 '15 at 13:04
  • 1
    The Clang documentation explicitly says that what it does is provide the C++ name mangling for C. And that's basically just the compiler automatically doing behind the scenes what one does in Objective-C by giving methods names that are distinct by encompassing (in longer form) the argument types. – Chris Stratton Jan 06 '17 at 20:46
20

David is correct in that method overloading is not supported in Objective-C. It is similar to PHP in that sense. As he also points out, it is common practice to define two or more methods with different signatures in the manner he examples. However, it is also possible to create one method using the "id" type. Via the "id" type, you can send any object (and any primitives using the NSNumber class) to the method and then from within the method itself you can test its type and throw the appropriate exception if necessary. Although this does have a minor performance hit, it will most likely be nominal or insignificant unless you are processing large quantities of data.

- (void) writeToFile: (NSString *)path fromObject: (id)object {
    if (!([object isKindOfClass: [NSNumber class]] || [object isKindOfClass: [NSString class]])) {
         @throw [NSException exceptionWithName: @"InvalidArgumentException" reason: @"Unrecognized parameter type." userInfo: nil];
    }
}

This is also a beautiful place to implement a protocol to enforce the object type, which can be done like so:

(id<MyProtocol>)object
Ziminji
  • 1,286
  • 1
  • 14
  • 18