4 ms·

What's going on here is Brent Simmons has been posting a series of blog articles expressing concern that very useful dynamic features used in Obj-C to great eff

by dottrap 10y ago

What's going on here is Brent Simmons has been posting a series of blog articles expressing concern that very useful dynamic features used in Obj-C to great effect cannot be currently done in pure Swift. And many of the old guard that is knowledgable in how Obj-C+Cocoa is implemented and have built their own powerful things on top of it are also expressing their same concern that Swift has not addressed how these things are going to be done without Obj-C. http://inessential.com/2016/05/18/what_im_doing_with_these_articles http://inessential.com/2016/05/18/what_im_doing_with_these_a... There are key technologies in Cocoa like the Responder Chain, NSUndoManager, Key-Value-Coding/Key-Value-Observing/Cocoa Bindings, Core Data, that are made possible due to Objective-C's dynamic features which allows for easy coding and also impressive decoupling. The concern is that some developers actually need to develop things like this and Swift doesn't offer anything comparable. Additionally, as Swift enters new platforms where Obj-C doesn't exist, or if Apple kills off Obj-C support, there is no obvious replacement for those who want/need to build systems like Cocoa. For right now, Swift is a good consumer of Cocoa, but not something you could implement Cocoa with.

chris_7 10y ago
> Responder Chain Protocols, or even a superclass. > NSUndoManager Closures. Even Apple has moved away from target/selector for new APIs in favor of blocks. > Key-Value-Coding/Key-Value-Observing/Cocoa Bindings An equivalent is easily implementable in pure Swift, see ReactiveCocoa's PropertyType/MutablePropertyType, and I'm sure someone has packaged something similar as a µframework so that you don't need to add all of RAC. > Core Data This one is actually hard, as it relies on dynamic generation of implementations, instead of using that to solve a different problem, as is the case with KVO. I'm willing to toss Core Data overboard to gain the safety and productivity of Swift, but YMMV.
- dottrap 10y ago
  It doesn't sound like you've read any of the articles. There are details and tradeoffs and limitations found by the people talking about them. And there is a massive knowledge vacuum because if there is a good solution, it's not something that is obvious and well discussed by Apple. Ignoring and dismissing them doesn't make them actually go away. Here's two on just the Responder chain: http://inessential.com/2016/05/17/responder_chain_followup http://inessential.com/2016/05/17/responder_chain_followup http://shapeof.com/archives/2016/5/dynamic_swift.html http://shapeof.com/archives/2016/5/dynamic_swift.html The bigger point (which is in that first Brent Simmons link) is that people have built all sorts of frameworks and tools over the past 20 years depending using of the dynamic features of Obj-C. Some are Apple's like all the above plus others like Interface Builder and XCTest, but other people have built their own things too that rely on the same concepts. How do these people move forward in a Swift world? None of these people are arguing that Swift is terrible and going back to Obj-C. They are trying to use Swift. They are only interested in solving the problems they have (and well). When Swift fails to solve a problem or is far worse than its predecessor, there is a problem. Not everybody can nonchalantly throw their stuff overboard like you are willing to do with Core Data.
  - kartickv 10y ago
    I've read those articles, but I still don't see why you need dynamic features to implement the responder chain. UIResponder can have implementations of all the methods that return NO. You override whichever you want to, and return YES. Then, instead of checking if a selector exists and then invoking it, the system just calls the method, and if it returns NO, it moves on to the next responder in the chain. What am I missing?
  - kartickv 10y ago
    I also agree with chris_7 that I'd prefer NSUndoManager to use blocks rather than selectors.
- phink 10y ago
  > Safety if (indexPath == 3) {...} Results in a warning in Objective C, none in Swift. Did you see that .row is missing? > Productivity How is (notification.userInfo?[UIKeyboardFrameBeginUserInfoKey] as? NSValue)?.CGRectValue() more productive than [[notification userInfo][UIKeyboardFrameBeginUserInfoKey] CGRectValue] Swift makes me waste my time on trivial things.

by dottrap 10y ago

chris_7 10y ago

> Responder Chain Protocols, or even a superclass. > NSUndoManager Closures. Even Apple has moved away from target/selector for new APIs in favor of blocks. > Key-Value-Coding/Key-Value-Observing/Cocoa Bindings An equivalent is easily implementable in pure Swift, see ReactiveCocoa's PropertyType/MutablePropertyType, and I'm sure someone has packaged something similar as a µframework so that you don't need to add all of RAC. > Core Data This one is actually hard, as it relies on dynamic generation of implementations, instead of using that to solve a different problem, as is the case with KVO. I'm willing to toss Core Data overboard to gain the safety and productivity of Swift, but YMMV.

dottrap 10y ago
It doesn't sound like you've read any of the articles. There are details and tradeoffs and limitations found by the people talking about them. And there is a massive knowledge vacuum because if there is a good solution, it's not something that is obvious and well discussed by Apple. Ignoring and dismissing them doesn't make them actually go away. Here's two on just the Responder chain: http://inessential.com/2016/05/17/responder_chain_followup http://inessential.com/2016/05/17/responder_chain_followup http://shapeof.com/archives/2016/5/dynamic_swift.html http://shapeof.com/archives/2016/5/dynamic_swift.html The bigger point (which is in that first Brent Simmons link) is that people have built all sorts of frameworks and tools over the past 20 years depending using of the dynamic features of Obj-C. Some are Apple's like all the above plus others like Interface Builder and XCTest, but other people have built their own things too that rely on the same concepts. How do these people move forward in a Swift world? None of these people are arguing that Swift is terrible and going back to Obj-C. They are trying to use Swift. They are only interested in solving the problems they have (and well). When Swift fails to solve a problem or is far worse than its predecessor, there is a problem. Not everybody can nonchalantly throw their stuff overboard like you are willing to do with Core Data.
- kartickv 10y ago
  I've read those articles, but I still don't see why you need dynamic features to implement the responder chain. UIResponder can have implementations of all the methods that return NO. You override whichever you want to, and return YES. Then, instead of checking if a selector exists and then invoking it, the system just calls the method, and if it returns NO, it moves on to the next responder in the chain. What am I missing?
- kartickv 10y ago
  I also agree with chris_7 that I'd prefer NSUndoManager to use blocks rather than selectors.
phink 10y ago
> Safety if (indexPath == 3) {...} Results in a warning in Objective C, none in Swift. Did you see that .row is missing? > Productivity How is (notification.userInfo?[UIKeyboardFrameBeginUserInfoKey] as? NSValue)?.CGRectValue() more productive than [[notification userInfo][UIKeyboardFrameBeginUserInfoKey] CGRectValue] Swift makes me waste my time on trivial things.