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@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution