How do you import the API to Swift when the target and action properties are separate?
Félix > Le 30 déc. 2015 à 09:36:24, James Campbell via swift-evolution > <[email protected]> a écrit : > > Ah good point, in swift you can return a function as a closure (see that > link) so interface builder could bind an action. Like so : > > addAction(myClass.actionFunction) > > Instead of what it does now: > > addAction(myClass, action:"actionFunction:") > > > Sent from my iPhone > >> On 30 Dec 2015, at 14:14, Jean-Daniel Dupas <[email protected]> wrote: >> >> >>> Le 30 déc. 2015 à 12:21, James Campbell via swift-evolution >>> <[email protected]> a écrit : >>> >>> These are very good points. >>>> >>>> Actually, it comes in as addAction(action: Selector), not String. You can >>>> initialize a Selector from a string literal. >>> >>> Yes :) should have looked it up before I tried to remember it off the top >>> of my head. >>> >>>> >>>> Three questions about your proposal: >>>> >>>> 1. Where does "AnyObject -> Void" come from? The only signature >>>> information in a selector is the (minimum) number of arguments. Those >>>> arguments can be of any type, and >>> >>> Well I would want to know what selectors people would us: >>> >>> One with one argument tend to be for events like button actions and >>> notifications which could be replaced by closures. We could deprecate or >>> provide warnings when trying to use the Selector Apis in swift. >>> >>> Others with more tend to be for canPerformSelector which is replaced by >>> optionals. >>> >>> The one edge case not handled is nsinvocation or performSelector, I would >>> be interested why people use this use case and how we would replace it in >>> swift (if at all). >>> >>>> >>>> 2. How are we supposed to implement this? You need to somehow convert a >>>> closure (a pointer to a bunch of captured variables with a pointer to a >>>> function embedded inside it) into a selector (a pointer to a table of >>>> selectors inside the Objective-C runtime, which does not do any normal >>>> memory management); I just don't see how you make that work. Saying "let's >>>> do this thing" doesn't mean it's *possible* to do the thing. >>> >>> I get that they are different but I had the idea that the compiler could >>> generate a unique name for each closure which when referenced by a selector >>> it would invoke. >>> >>> But this would be irrelevant if we moved towards closure Apis. >>> >>>> 3. What about other uses for selectors? addAction() is all well and good, >>>> but you also need removeAction(), and Swift closures don't have stable >>>> identities to test with. >>> >>> I question when we use things such as removeAction? I've only used >>> addAction. But I guess again if we moved to closure Apis this point would >>> be moot. >>> >>> To me the only case that needs selectors is performSelector or >>> Nsinvocation. The others can be replaced by closures and the selector api >>> to be deprecated or to show a warning in swift :) (Xcode could even help >>> migrate by moving it to a closure that calls the function the selector was >>> pointing to) >>> >>> I'm not a compiler expert so I rely on the swift team to tell me what's >>> possible (although at this early stage I think it's more important to >>> figure out what we want and not be bound by what's possible right now) >> >> How would the closure based API work with Interface Builder ? >> > _______________________________________________ > 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
