> 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
