Do you have an example of use ? Sent from my iPhone
> On 30 Dec 2015, at 15:48, Félix Cloutier <[email protected]> wrote: > > 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
