[swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

Wed Dec 30 04:14:46 CST 2015

+1 for that. Closures are much more swift-y than selectors (and honestly,
even in Objective-C, selectors are a pain to use). This would definitely be
nice, although I'm not quite sure if it's possible with reasonable effort.
Selectors are very, very different beasts.

On Wed, Dec 30, 2015 at 10:56 AM, James Campbell via swift-evolution <
swift-evolution at swift.org> wrote:

> What if selectors arguments could be imported into swift to take a closure
> instead ?
>
> This would fit into the proposal to rewrite the imported objective c Apis
>
> So
>
> - addAction:(Selector)action
>
> Becomes
>
> addAction(action:(AnyObject)->Void)
>
> Instead of
>
> addAction(action:String)
>
> Like it does now.
>
> Sent from my iPhone
>
> On 29 Dec 2015, at 21:46, Joe Groff via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Dec 29, 2015, at 12:19 PM, Douglas Gregor via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
>
> Sent from my iPhone
>
> On Dec 27, 2015, at 12:07 AM, Jacob Bandes-Storch <jtbandes at gmail.com>
> 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 <
> swift-evolution at 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
>> ).
>>
>> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>

-- 
Author of the Sparkling language
http://h2co3.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151230/ec6f6b39/attachment.html>