[swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

[James Campbell]

Ah good point, in swift you can return a function as a closure (see that link) so interface builder could bind an action. Like so :

addAction(myClass.actionFunction)

Instead of what it does now:

addAction(myClass, action:"actionFunction:")


Sent from my iPhone

> On 30 Dec 2015, at 14:14, Jean-Daniel Dupas <mailing at xenonium.com> wrote:
> 
> 
>> Le 30 déc. 2015 à 12:21, James Campbell via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>> These are very good points. 
>>> 
>>> Actually, it comes in as addAction(action: Selector), not String. You can initialize a Selector from a string literal.
>> 
>> Yes :) should have looked it up before I tried to remember it off the top of my head.
>> 
>>> 
>>> Three questions about your proposal:
>>> 
>>> 1. Where does "AnyObject -> Void" come from? The only signature information in a selector is the (minimum) number of arguments. Those arguments can be of any type, and
>> 
>> Well I would want to know what selectors people would us:
>> 
>> One with one argument tend to be for events like button actions and notifications which could be replaced by closures. We could deprecate or provide warnings when trying to use the Selector Apis in swift.
>> 
>> Others with more tend to be for canPerformSelector which is replaced by optionals.
>> 
>> The one edge case not handled is nsinvocation or performSelector, I would be interested why people use this use case and how we would replace it in swift (if at all).
>> 
>>> 
>>> 2. How are we supposed to implement this? You need to somehow convert a closure (a pointer to a bunch of captured variables with a pointer to a function embedded inside it) into a selector (a pointer to a table of selectors inside the Objective-C runtime, which does not do any normal memory management); I just don't see how you make that work. Saying "let's do this thing" doesn't mean it's *possible* to do the thing.
>> 
>> I get that they are different but I had the idea that the compiler could generate a unique name for each closure which when referenced by a selector it would invoke.
>> 
>> But this would be irrelevant if we moved towards closure Apis.
>> 
>>> 3. What about other uses for selectors? addAction() is all well and good, but you also need removeAction(), and Swift closures don't have stable identities to test with.
>> 
>> I question when we use things such as removeAction? I've only used addAction. But I guess again if we moved to closure Apis this point would be moot.
>> 
>> To me the only case that needs selectors is performSelector or Nsinvocation. The others can be replaced by closures and the selector api to be deprecated or to show a warning in swift :) (Xcode could even help migrate by moving it to a closure that calls the function the selector was pointing to)
>> 
>> I'm not a compiler expert so I rely on the swift team to tell me what's possible (although at this early stage I think it's more important to figure out what we want and not be bound by what's possible right now)
> 
> How would the closure based API work with Interface Builder ? 
>