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

Chris Lattner clattner at nondot.org
Sun Dec 3 11:39:53 CST 2017

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.


> 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:


having to write:


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.


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

More information about the swift-evolution mailing list