Would it be possible to add properties to closures/method objects?
Right now, it's possible to write:
> @objc
> class Foo : NSObject {
> func doSomething(value: Int) -> Int {
> return value + 1
> }
> }
>
> let method = Foo.doSomething
Maybe we could have Foo.doSomething.selector for @objc methods?
Félix
> Le 27 déc. 2015 à 15:55:31, Javier Soto via swift-evolution
> <swift-evolution@swift.org> a écrit :
>
> 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?")
> On Sun, Dec 27, 2015 at 10:07 AM Joe Groff via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> > On Dec 26, 2015, at 11:48 PM, Douglas Gregor via swift-evolution
> > <swift-evolution@swift.org <mailto: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
> >
> > <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.
>
> 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.
>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> --
> Javier Soto _______________________________________________
> 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
