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
