Are selectors in objective - c just another way to send a message to an object? I really don't understand why or how to use them.
views:
66answers:
2
+1
A:
At the most basic, yes, but you can change the message at runtime. For example:
SEL a = [selectorFactory getSelector];
[someOtherObject performSelector:a];
And then in selectorFactory.getSelector:
if(foo == 1)
return @selector(thisSelector);
else
return @selector(thatSelector);
Coming from C# or another similar language, you can use this to (loosely) simulate events much more easily than using NSNotifications. For example, you could make a button class with two ivars, target and selector, and have the button perform the selector on the target when it's clicked (for example).
There's a lot more to selectors than that, though. Read more about them here:
Ian Henry
2010-08-22 20:18:08
+3
A:
They aren’t another way to send a message to an object, they’re the only way. For example, in [myView setValue:@"foo"], setValue: is a selector. (Another, less convenient way of writing the same thing is objc_msgSend(myView, @selector(setValue:), @"foo").)
As Ian Henry says, you can use SEL values to choose a selector at runtime instead of compile time. This is a fundamental technique in Cocoa; user interfaces are generally connected to controllers using target/action bindings, where the target is an object and the action is a selector. Normally you set this up in a nib, but you can also do it in code:
[myButton setTarget:myController];
[myButton setAction:@selector(buttonClicked:)]; // Clicking the button will now call [myController buttonClick:myButton].
Ahruman
2010-08-22 21:16:20
Great answer, but what is the advantage of doing: [myButton setAction:@selector(buttonClicked)] Instead of sending the message to myController directly with a "normal" message?
lampShade
2010-08-22 22:11:03
By setting the action, the message is sent when the button is clicked. If you send the message directly, it happens “now” (i.e., when the UI is set up). Having all your buttons clicked immediately when you load a window isn’t generally useful.
Ahruman
2010-08-22 23:06:07
Let me make sure I understand what you're saying. lets say that I have a button, myButton that is in the UI. If I set up a "normal" target action in interface builder. Lets' say that I have a method called addItem. When the UI is loaded the addItem method is automatically called - even if the user has not pushed the button?
lampShade
2010-08-22 23:17:17
No--think of a selector as the *name* of a method. When you set a button's action, you're telling that button the *name* of the message it should send when the user clicks it. So the button can send that message as many times as it needs to, when it needs to, and you-the-programmer don't need to be involved.
Jonathan Grynspan
2010-08-22 23:22:09
lampShade: No, that's what happens if you send the `addItem:` message to yourself directly *instead* of setting it as the action of the button. The button becomes not involved. The button is only involved when you set yourself as its target (in IB or in code; it doesn't matter which) and `addItem:` as its action, and the message is only sent when the user clicks on the button, which causes the button to send its action message to its target. (Also, selectors for actions in Cocoa must take one argument, hence the : I've appended to `addItem:` in this comment.)
Peter Hosey
2010-08-23 03:58:20