[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Jonathan Hull]

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