[swift-evolution] Three questions about a more "dynamic" Swift for InfoQ

[Johannes Neubauer]

Von meinem iPhone gesendet

> Am 26.09.2016 um 23:32 schrieb Robert Widmann via swift-evolution <swift-evolution at swift.org>:
> 
> 
> 
> ~Robert Widmann
> 
> 2016/09/26 16:29、sergio via swift-evolution <swift-evolution at swift.org> のメッセージ:
> 
>> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160926/d7a8d619/attachment.html>