In the performSelector and nsinvocation case. Are people using it for existing functions in which case type safety is important.
But if it's for dynamic calling of a method ( for example for a visitor pattern) then I don't think there is any safety that can easily be applied via a special syntax and if it can it would be done another way. I think in most cases the selector has been replaced in swift. Sent from my iPhone > On 30 Dec 2015, at 11:21, James Campbell <[email protected]> wrote: > > 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
