On Dec 3, 2017, at 5:45 AM, Jonathan Hull <jh...@gbis.com> wrote: > Hi Chris, > > I am definitely in favor of providing dynamic features in Swift, and of being > able to interoperate easily with dynamic languages. I really like the idea > overall.
Great! > > I was about to write up a different idea I had for partially mitigating some > of the issues around being able to mistype method names, etc…, but then I > remembered a usability principle that I first heard from members of the Lisa > team (discovered the hard way): Things which behave the same should look the > same, and things which behave differently need to look different. That’s a good principle. However, a dynamic member lookup is just a member lookup. By that principle, it should look like a member lookup :-) Further, I incorporated some of the conversation with Matthew into the proposal, showing how adding even a single sigil to dynamic member lookup to distinguish it is problematic: https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#increasing-visibility-of-dynamic-member-lookups <https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#increasing-visibility-of-dynamic-member-lookups> Further, adding something like .dynamic would completely undermind the proposal. You can already write: x.get(“foo”).get(“bar”) having to write: x.dynamic.foo.dynamic.bar has no point. > What this means is that it is easy to wrap commonly used calls in a normal > swift method: > > func addTrick(_ name:String) { > self.dynamic.add_trick(name) > } This would require wrapping all calls for them to be usable. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
