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.
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.
I like that the change in behavior is really limited in scope by this proposal,
but there still isn’t really any indication other than the type (which might be
inferred) that the normal checking behavior is offline. When in a fully
dynamic environment, this isn’t really a big problem because you use different
debugging strategies, but I worry that the free mixture of static and dynamic
without any indicators showing the difference will lead to much more frequent
errors.
What do you think about having a special method ‘dynamic' defined in this
protocol, such that the compiler magic lookup behavior is only available when
chained after that method? Thus:
dog.add_trick(“sit”)
would have to be:
dog.dynamic.add_trick(“sit”)
Now, I know that sounds like a pain in the butt, but it also buys you an extra
ability (in addition to the extra cue that we have to watch out for dynamic
issues). Because the dynamic lookup only happens for calls chained after
dynamic, we now have normal swift lookup for all of the other
methods/properties defined on the type (with autocomplete support, etc…).
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)
}
Now the user can say the following with full autocomplete support, type
checking, etc…
addTrick(“sit”)
…and if they misspell it, they will get an error from the compiler. Error
handling could also optionally be added to a wrapper. Most importantly,
conversion to/from swift return types and parameters can easily be built into
the wrappers.
The end result is a system where python code can be up and running in Swift
very quickly (by using chaining with .dynamic), and then made more native Swift
friendly incrementally over time (by adding wrappers/extensions for
common/important calls). The only extra cost is having to type an extra word
for dynamic calls without wrappers.
Thoughts?
Thanks,
Jon
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
