<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;"><br></div><br>Von meinem iPhone gesendet</div><div><br>Am 26.09.2016 um 23:32 schrieb Robert Widmann via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><span></span></div><div><div><div style="direction: inherit;"><br></div><br>~Robert Widmann</div><div><br>2016/09/26 16:29、sergio via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> のメッセージ:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">HI all,<div class=""><br class=""></div><div class="">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). </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">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?<br class=""></b></div></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">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.</div></div></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">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.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">All the best</div><div style="direction: inherit;">Johannes</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><div class=""><b class=""><br class="">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.]<br class=""></b></div></div></blockquote><div><br></div><div>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 <i>because </i>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.</div><br><blockquote type="cite"><div><div class=""><b class=""><br class=""></b></div><div class="">Thanks a lot in advance!<br class="">Sergio<br class=""><br class="">—<br class=""><br class="">Sergio De Simone<br class=""><a href="https://www.infoq.com/author/Sergio-De-Simone" class="">https://www.infoq.com/author/Sergio-De-Simone</a></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>