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

[Jacob Bandes-Storch]

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:)`) ?

- 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`"

- Should the migrator offer to convert string-constant selectors to this
form?

- It might be worth considering this in the context of the "type-safe
selectors" idea that was floating around a while back.

- 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?

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).

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151227/9409201e/attachment.html>