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) > > -- > Brent Royal-Gordon > Architechies > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
