What if you could just refer to it by pointing to a special property ? button.addTarget( class.prototype.handlePress)
If it has parameters these could be specified like so button.addTarget(class.prototype.handlePress(sender:)) Sent from my iPhone > On 29 Dec 2015, at 21:46, Joe Groff via swift-evolution > <[email protected]> wrote: > > >> On Dec 29, 2015, at 12:19 PM, Douglas Gregor via swift-evolution >> <[email protected]> wrote: >> >> >> >> 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. > > 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 >>>> <[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 > > > _______________________________________________ > 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
