Some people claim that Objective-C’s selectors (function names with parameters infixed) are just functions with named arguments.
Here’s a very simple proof that selectors aren’t named arguments:
- (void)fooThis:(int)firstArgument andThis:(int)secondArgument andThis:(int)thirdArgument
That’s the signature of an Objective-C instance method with the fooThis:andThis:andThis: selector. Treating the selector parts as named arguments would be impossible – would the argument whose name is ‘andThis’ correspond to the second or third argument?
Not to mention that you actually don’t need names in all places, or even any place. This is a perfectly valid method specification:
- (NSArray *)arrayWithThreeObjects:(id)object :(id)object :(id)object
Update: This is another: - (void):(id)object :(id)object :(id)object. (See also: AEVTBuilder.) Thanks to Jens Ayton in the comments.
Update: Special DVD extra material follows!
Lastly, I’ve used the terms ‘selector’, ‘method’ and ‘signature’ here. What’s the difference?
The selector is simply this: fooThis:andThis:andThat:. This is the parallel to the C function name (sayHello), and they both compile down to ‘symbols’ – this is why the selector segments are non-reorderable, by the way, because actually, somewhere in the dank annals of the Objective-C runtime and compiler tag team, the selector is turned into a function name.
The signature is this: (void)fooThis:(int)firstArgument andThis:(int)secondArgument andThis:(int)thirdArgument. This is parallel to the C signature (void sayHello(char *string)), in that it includes type information and the variables the arguments are assigned to. Strictly speaking, the variable names are not part of the method’s signature. (In C# and Java, methods can have multiple definitions with the same function name, as long as they have different signatures – aka you can have both void sayFoo() and void sayFoo(String why, int howManyTimes).)
The method is the pair of method specification – which is a + for a class method or a - for an instance method, followed by the signature and all inside a class @interface block – and the method implementation, which is the method specification followed by a block, inside a class @implementation block.
When explaining Objective-C method names and calling to people, I compare it to a Mad-Lib. An method invocation is a phrase; the colon means you should fill in the blank. If the interface follows convention this usually makes sense.
I’m not a big fan of allowing parameters that don’t have names before them because doing so them obscures an error I make all the time:
- (void) setFoo:(NSString *) forBar:(NSString *)bar;This above compiles fine, but since I forgot to give the first string a variable name, the signature of the method is -setFoo:: rather than -setFoo:forBar: as I intended. I don’t notice the error until I attempt to either call the method or use the non-existant parameter in the method implementation.
I make this error probably once a week and have never had occassion to use parameters without names before them, so the tradeoff between flexibility and early error detection doesn’t work in my favor.
By Devin Coughlin · 2007.02.20 18:45
Unnamed selector parts aren’t the highlight of my day either.
By Jesper · 2007.02.20 18:49
Very few people know about unnamed selector parts. Kudos++.
By Scott Stevenson · 2007.02.20 20:38
It is in fact possible to omit all “name” parts, and use a selector consisting entirely of colons, as seen in AEVTBuilder.
By Jens Ayton · 2007.02.21 14:04