<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPhone</div><div><br>On Dec 27, 2015, at 12:07 AM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com">jtbandes@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">This is a neat idea. Here are some of my thoughts after initial readthrough:<div><br></div><div>- For symmetry with Obj-C code, how about using "@selector", such as @selector(UIView.`insertSubview(_:at:)`) ?</div></div></div></blockquote><div><br></div>@ means at-tribute in Swift, whereas this is a specific expression. <div><br><blockquote type="cite"><div><div dir="ltr"><div>- 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`"</div></div></div></blockquote><div><br></div><div>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. </div><br><blockquote type="cite"><div><div dir="ltr"><div>- Should the migrator offer to convert string-constant selectors to this form?</div></div></div></blockquote><div><br></div>Yes, absolutely.</div><div><br><blockquote type="cite"><div><div dir="ltr"><div>- It might be worth considering this in the context of the "type-safe selectors" idea that was floating around a while back.</div></div></div></blockquote><div><br></div>Yes, I should have referenced that. Apologies!</div><div><br><blockquote type="cite"><div><div dir="ltr"><div>- 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?</div></div></div></blockquote><div><br></div>Yes. MyView still has that property even if it doesn't override it. <br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>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).</div></div></div></blockquote><div><br></div>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. </div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div>Jacob Bandes-Storch<br></div></div></div></div>
<br><div class="gmail_quote">On Sat, Dec 26, 2015 at 11:48 PM, Douglas Gregor via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi all,<br>
<br>
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:<br>
<br>
control.sendAction(“doSomething:”, to: target, forEvent: event)<br>
<br>
There are many points of failure here:<br>
<br>
1) The compiler doesn’t syntax-check at all to make sure it’s a valid spelling for a selector<br>
2) The compiler doesn’t look for existing methods with this selector anywhere<br>
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 (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md</a>).<br>
<br>
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:<br>
<br>
control.sendAction(objc_selector(MyApplication.doSomething), to: target, forEvent: event)<br>
<br>
“doSomething” is a method of MyApplication, which might even have a completely-unrelated name in Objective-C:<br>
<br>
extension MyApplication {<br>
@objc(jumpUpAndDown:)<br>
func doSomething(sender: AnyObject?) { … }<br>
}<br>
<br>
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.<br>
<br>
This proposal composes with my “Generalized Naming for Any Function” proposal, which lets us name methods fully, including getters/setters:<br>
<br>
let sel1: Selector = objc_selector(UIView.`insertSubview(_:at:)`) // produces the Selector “insertSubview:atIndex:"<br>
let sel2: Selector = objc_selector(UIView.`frame.get`) // produces the Selector “frame"<br>
<br>
I don’t like the `objc_selector` syntax at all, but otherwise I think this functionality is straightforward.<br>
<br>
- Doug<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div><br></div></div>
</div></blockquote></div></body></html>