If I need to take this question elsewhere, please point me to the right list.
I decided to take the dive this morning and give XCode9 beta and Swift 4 a try. I’m tired of not being able to refactor.
There are two things that the importer is trying to commonly change that I’m curious about:
1) Anywhere I’ve linked a UIControl to a method via the addTarget(self, action: #selector(foobar), for: .valueChanged), it now feels that foobar needs to be annotated as @objc. I really liked that so far in my swift journey, I’ve never had to put one of these @objc things in. I think I get what’s going on. My class is a swift class, but is a subclass from UIViewController, an objc class. While apparently, it could infer that subclass methods should be objc callable, they no longer are?
What’s frustrating is that if UIControl just had an action API that used closures instead of the older perform: patterns, I’d just rewrite these as such. But it still doesn’t. So people still make extensions which have to resort to static globals or associated_objects.
2) I have a couple of CALayer subclasses that have a couple different ways of setting/accessing the same thing. I use dynamic vars for those. Once upon a time, someone told me that I needed to make them dynamic for the animation engine to correctly note changes to them. Apparently, those all need to be tagged @objc now. Which seems redundant to me. Are not dynamic vars already implicitly objc anyway? Is the new need to add @objc just for consistency sake?
If I need to take this question elsewhere, please point me to the right list.
I decided to take the dive this morning and give XCode9 beta and Swift 4 a try. I’m tired of not being able to refactor.
There are two things that the importer is trying to commonly change that I’m curious about:
1) Anywhere I’ve linked a UIControl to a method via the addTarget(self, action: selector(foobar), for: .valueChanged), it now feels that foobar needs to be annotated as @objc. I really liked that so far in my swift journey, I’ve never had to put one of these @objc things in. I think I get what’s going on. My class is a swift class, but is a subclass from UIViewController, an objc class. While apparently, it could infer that subclass methods should be objc callable, they no longer are?
What’s frustrating is that if UIControl just had an action API that used closures instead of the older perform: patterns, I’d just rewrite these as such. But it still doesn’t. So people still make extensions which have to resort to static globals or associated_objects.
2) I have a couple of CALayer subclasses that have a couple different ways of setting/accessing the same thing. I use dynamic vars for those. Once upon a time, someone told me that I needed to make them dynamic for the animation engine to correctly note changes to them. Apparently, those all need to be tagged @objc now. Which seems redundant to me. Are not dynamic vars already implicitly objc anyway? Is the new need to add @objc just for consistency sake?
This is also part of SE-0160. The reason dynamic no longer implies @objc is that one day we could make dynamic work independent of the Objective-C runtime, and support it on Linux too for instance.
Slava
···
On Aug 28, 2017, at 1:58 PM, Travis Griggs via swift-users <swift-users@swift.org> wrote: