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

[Chris Lattner]

On Dec 3, 2017, at 5:45 AM, Jonathan Hull <jhull at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171203/4127fcc1/attachment.html>