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

Javier Soto javier.api at gmail.com
Sun Dec 27 14:55:31 CST 2015


I would add to what Joe mentioned above the fact that the concept of
"selector" may not mean a whole lot to developers who are first introduced
to Swift without any prior Obj-C or Cocoa experience. Thinking of them as
functions I believe avoids introducing complexity in the form of additional
concepts that one must understand and differentiate ("what's a selector and
why/how is it different from a function value?")
On Sun, Dec 27, 2015 at 10:07 AM Joe Groff via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On 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.
>
> Selectors can be seen as "just" a kind of function value. Do we need a new
> syntax form at all? We ought to be able to turn an unbound function
> reference like UIView.insertSubview into a selector reference in Selector
> type context, or maybe a typed @convention(selector) function as discussed
> in another thread, without any explicit get-a-selector operation.
>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151227/70b5a05c/attachment.html>


More information about the swift-evolution mailing list