Sent from my iPhone
> On Dec 27, 2015, at 12:07 AM, Jacob Bandes-Storch <[email protected]> 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. > - 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 >> <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
