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

[James Campbell]

What if selectors arguments could be imported into swift to take a closure instead ? 

This would fit into the proposal to rewrite the imported objective c Apis 

So 

- addAction:(Selector)action

Becomes

addAction(action:(AnyObject)->Void)

Instead of

addAction(action:String) 

Like it does now.

Sent from my iPhone

> On 29 Dec 2015, at 21:46, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Dec 29, 2015, at 12:19 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Dec 27, 2015, at 12:07 AM, Jacob Bandes-Storch <jtbandes at gmail.com> wrote:
>>> 
>>> This is a neat idea. Here are some of my thoughts after initial readthrough:
>>> 
>>> - For symmetry with Obj-C code, how about using "@selector", such as @selector(UIView.`insertSubview(_:at:)`) ?
>> 
>> @ means at-tribute in Swift, whereas this is a specific expression. 
>> 
>>> - Or, why bother with a new expression? Could the compiler just do this automatically when it encounters an @objc function being passed as a Selector? So, you'd simply be able to say "let sel1: Selector = UIView.`frame.get`"
>> 
>> It could, but I don't think it should: the operation is not common enough that making it implicit would reduce overall syntactic noise, and it would introduce ambiguities between selector- and closure-based APIs. 
> 
> Maybe we can make constructor-like "Selector(Class.method)" syntax work (and "Selector(getterFor:/setterFor: Class.property)" for property accessors) instead of introducing a new magic function name.
> 
> -Joe
> 
>>> - Should the migrator offer to convert string-constant selectors to this form?
>> 
>> Yes, absolutely.
>> 
>>> - It might be worth considering this in the context of the "type-safe selectors" idea that was floating around a while back.
>> 
>> Yes, I should have referenced that. Apologies!
>> 
>>> - Would it be valid to qualify a function with a subclass's name, when it's really only defined on the superclass? That is, would "objc_selector(MyView.`frame.get`)" work even if MyView doesn't override the `frame` property?
>> 
>> Yes. MyView still has that property even if it doesn't override it. 
>>> 
>>> I could see this last one as a potential source of user confusion, because naming a particular class wouldn't actually tell you which implementation gets called when performing the selector (that's just the nature of the Obj-C runtime).
>> 
>> To some extent, that's the nature of overriding. But objective-c allows one to use a selector with an unrelated class, which can certainly be confusing. I feel like that comes from the runtime itself, and isn't something we can avoid with any syntax we pick. 
>> 
>>> Jacob Bandes-Storch
>>> 
>>>> On Sat, Dec 26, 2015 at 11:48 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
>>>> Hi all,
>>>> 
>>>> Currently, producing an Objective-C selector in Swift is an error-prone operation. One effectively just writes a string literal and uses it in a context where an ObjectiveC.Selector is expected:
>>>> 
>>>>         control.sendAction(“doSomething:”, to: target, forEvent: event)
>>>> 
>>>> There are many points of failure here:
>>>> 
>>>> 1) The compiler doesn’t syntax-check at all to make sure it’s a valid spelling for a selector
>>>> 2) The compiler doesn’t look for existing methods with this selector anywhere
>>>> 3) The mapping from a Swift method name to an Objective-C selector isn’t always immediately obvious (especially for initializers), and will be getting significantly more complicated with the renaming work for Swift 3 (https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md).
>>>> 
>>>> I suggest that we add an expression ‘objc_selector(method-reference)` that produces the Objective-C selector for the named method, and produces an error if the method does not have an Objective-C entry point. For example:
>>>> 
>>>>         control.sendAction(objc_selector(MyApplication.doSomething), to: target, forEvent: event)
>>>> 
>>>> “doSomething” is a method of MyApplication, which might even have a completely-unrelated name in Objective-C:
>>>> 
>>>>         extension MyApplication {
>>>>                 @objc(jumpUpAndDown:)
>>>>                 func doSomething(sender: AnyObject?) { … }
>>>>         }
>>>> 
>>>> By naming the Swift method and having objc_selector do the work to form the Objective-C selector, we free the programming from having to do the naming translation manually and get static checking that the method exists and is exposed to Objective-C.
>>>> 
>>>> This proposal composes with my “Generalized Naming for Any Function” proposal, which lets us name methods fully, including getters/setters:
>>>> 
>>>>         let sel1: Selector = objc_selector(UIView.`insertSubview(_:at:)`) // produces the Selector “insertSubview:atIndex:"
>>>>         let sel2: Selector = objc_selector(UIView.`frame.get`) // produces the Selector “frame"
>>>> 
>>>> I don’t like the `objc_selector` syntax at all, but otherwise I think this functionality is straightforward.
>>>> 
>>>>         - Doug
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151230/50d9f870/attachment-0001.html>