NSControl and subclasses have an action property and a target property but no method to set both at once (in opposition to, say, NSTimer, which has methods that accept a target and a selector at the same time).
Félix > Le 30 déc. 2015 à 11:52:41, James Campbell <ja...@supmenow.com> a écrit : > > Do you have an example of use ? > > Sent from my iPhone > >> On 30 Dec 2015, at 15:48, Félix Cloutier <felix...@yahoo.ca> 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 >>> <swift-evolution@swift.org> 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 <mail...@xenonium.com> wrote: >>>> >>>> >>>>> Le 30 déc. 2015 à 12:21, James Campbell via swift-evolution >>>>> <swift-evolution@swift.org> 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 >>> 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
