<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Would it be possible to add properties to closures/method objects?</div><div class=""><br class=""></div><div class="">Right now, it's possible to write:</div><div class=""><br class=""></div><div class=""><div class=""></div></div><blockquote type="cite" class=""><div class=""><div class="">@objc</div><div class="">class Foo : NSObject {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func doSomething(value: Int) -> Int {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>return value + 1</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="">}</div></div><div class=""><br class=""></div><div class="">let method = Foo.doSomething</div></blockquote><div class=""><br class=""></div><div class="">Maybe we could have Foo.doSomething.selector for @objc methods?</div><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; line-height: normal; border-spacing: 0px;">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 27 déc. 2015 à 15:55:31, Javier Soto via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class="">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?")<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, Dec 27, 2015 at 10:07 AM Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
> On Dec 26, 2015, at 11:48 PM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> Hi all,<br class="">
><br class="">
> 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 class="">
><br class="">
> control.sendAction(“doSomething:”, to: target, forEvent: event)<br class="">
><br class="">
> There are many points of failure here:<br class="">
><br class="">
> 1) The compiler doesn’t syntax-check at all to make sure it’s a valid spelling for a selector<br class="">
> 2) The compiler doesn’t look for existing methods with this selector anywhere<br class="">
> 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" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md</a>).<br class="">
><br class="">
> 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 class="">
><br class="">
> control.sendAction(objc_selector(MyApplication.doSomething), to: target, forEvent: event)<br class="">
><br class="">
> “doSomething” is a method of MyApplication, which might even have a completely-unrelated name in Objective-C:<br class="">
><br class="">
> extension MyApplication {<br class="">
> @objc(jumpUpAndDown:)<br class="">
> func doSomething(sender: AnyObject?) { … }<br class="">
> }<br class="">
><br class="">
> 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 class="">
><br class="">
> This proposal composes with my “Generalized Naming for Any Function” proposal, which lets us name methods fully, including getters/setters:<br class="">
><br class="">
> let sel1: Selector = objc_selector(UIView.`insertSubview(_:at:)`) // produces the Selector “insertSubview:atIndex:"<br class="">
> let sel2: Selector = objc_selector(UIView.`frame.get`) // produces the Selector “frame"<br class="">
><br class="">
> I don’t like the `objc_selector` syntax at all, but otherwise I think this functionality is straightforward.<br class="">
<br class="">
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.<br class="">
<br class="">
-Joe<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div><div dir="ltr" class="">-- <br class=""></div>Javier Soto
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=iRI3beHTe3UxYAHTlV3lA38zIPfHMhyuRzgTmGKV6k7hcGmI3Qqlapw01-2FO1m9ZDlOf5twHOyocpdJWqZpEzYF3wRwl-2F0n-2FQ2AB8vtJ-2FKwRjidWe1ERsQPY3cbN-2BsFKxkItq9iHMedLTL59Ih3YsxW6yAIlfWE-2BHf5AymLsoVnpgFmHxiIXLPTEtmlz0azc-2BM0V0EPBudbKNmtKENcm8Pz-2BobUigLY1ovJmdRKGOmjY-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>