Von meinem iPhone gesendet
> Am 26.09.2016 um 23:32 schrieb Robert Widmann via swift-evolution > <[email protected]>: > > > > ~Robert Widmann > > 2016/09/26 16:29、sergio via swift-evolution <[email protected]> > のメッセージ: > >> HI all, >> >> a debate has recently taken place within the Objective-C/Swift dev community >> concerning the lack in Swift of something “equivalent” to Objective-C >> runtime programming. When using Swift exclusively, there seems to be no easy >> equivalent for Cocoa fundamental design patterns such as the Responder >> Chain, NSUndoManager, KVC/KVO/Bindings — and in general for code that >> leverages Objective-C's dynamic features (i.e., runtime programming). >> >> According to some developers, dynamic features in Ocjective-C grant easy >> coding and high decoupling and there are concerns that Swift might make >> harder a number of common Objective-C tasks (e.g., by increasing boilerplate >> code, lowering readability, making high use of switch, etc.) and eventually >> increase development time. >> >> In this context, is interesting to know how those concerns are viewed within >> the Swift dev community and how they could be tackled. Thus, I would like to >> ask three questions that will be the base for an InfoQ article on the topic: >> >> >> 1. Do you envision a more dynamic Swift? Should some level of dynamism >> be added at the language or framework level (e.g., to make dynamic dispatch >> or some form of message passing possible, while ruling out trickier features >> such as method swizzling and others) possible ? Should Swift be dynamic at >> all? > > No, and I think moving towards a more dynamic Swift now without > as-of-yet-seen significant justification would be a mistake. Swift should be > as static as possible. We should be making every attempt to pare down the > existing runtime and quietly transition those that rely on dynamism to > checked reflection (yes, that is not in fact an oxymoron). The more the > compiler knows about your program, the better it does. Period. I do not agree (fully). Although static type checking is great, object orientation is too. Dynamic dispatch and therefore (subtype) polymorphism is a wonderful thing. Going down the road to make every call static is an extreme that won't help anybody. As always the right balance makes the deal. All the best Johannes > >> >> 2. What is the challenge of making a more dynamic Swift (or adding >> features to it to help solve the same kind of issues that are solved in ObjC >> through dynamism)? How could that be achieved without making Swift a less >> safe language? [e.g., reflection, macros, etc.] > > There are very few dynamic patterns that aren't subsumed by the current > model. That said, two big ones I know of are Realm's approach of using > "runtime-metaprogramming" to derive models and combining static typing with > Clojure-style coercible data structures that share a common core. The first > can be subsumed by better reflection primitives, the second is more > difficult. Static Swift means room for potential optimizations that could > destroy the integrity of any system that thinks it knows enough to coerce > terms around itself (this kind of programming is powerful precisely because > of this knowledge). Perhaps that's not a bad thing. If you know your types > ahead of time - which you do if you're trying to perform coercions - you > should be able to write down something to convince the type checker. If you > can't, it's an expressiveness problem we should deal with at the level of the > type system. > >> >> Thanks a lot in advance! >> Sergio >> >> — >> >> Sergio De Simone >> https://www.infoq.com/author/Sergio-De-Simone >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
