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

[Jonathan Hull]

> On Dec 3, 2017, at 9:39 AM, Chris Lattner <clattner at nondot.org> wrote:
> 
> On Dec 3, 2017, at 5:45 AM, Jonathan Hull <jhull at gbis.com <mailto: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 :-)

The behavior is different though (the invisible guard rails which we normally rely on to prevent mistakes are missing), so it should look similar without being identical.

If Swift were entirely dynamic, there wouldn’t be an issue here, because developers would have strategies for dealing with it. It is the rarity of use that causes the issue here.  Swift developers have built up trust in the system to catch their typing mistakes, so if we make it so that the system can silently fail, there will be an increased error rate (above what you would have in a purely dynamic system).

Let me give a non-computer analogy. There are lots of arguments about whether the toilet seat should always be put down for the next user or just be left in it’s current position.  Some households have them randomly up or down based on who used them last. This equates to the dynamic case because no trust can be built that the seat will be down, so everyone learns to check before sitting. Let’s say we add a foot pedal though, which raises the seat when you step on it, and lowers it when it is not pressed (like a garbage can lid).  Now everyone can reason about the state of the system and can trust that it will be down unless they step on the pedal.  As a result, over time, people will be able to just sit without checking.  This is great, but if we re-introduce a little bit of dynamism (let’s say someone can lift the seat without using the pedal and it will stay up)… now the people who have built trust in the system, and just sit, will fall in.

The end result is that either some trust is lost in the system as a whole (people use the dynamic way of thinking when they don’t need to) or they continue to have errors when dealing with the rare dynamic cases.

I also like Paul’s suggestion of different syntax coloring for the dynamic calls.  In the toilet seat analogy, it is like one of those little lights you can buy that turns green or red depending on whether the seat is up or down.


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

Oh no, I meant a single ‘dynamic’ would enable dynamic lookup for the entire chain, so it would be:

	x.dynamic.foo.bar

This is different than requiring a sigil for each lookup.


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

I don’t think that chaining with ‘dynamic' is too large of a burden (when it works for the entire chain), so that would be the fallback for calls that haven’t been wrapped. Even if calls are never wrapped, I think this is workable.

My expectation though is that frequently used calls would end up getting wrapped eventually, and the wrappers would covert to/from Swift types.  Basically, I want a system which encourages people to thoughtfully Swift-ify™ the interface for working with python code incrementally over time. Python coders may have no incentive to do this, but Swift users of that code sure do.

I guess what I am arguing is that we should prioritize/optimize the ease of creating that translation layer at the cost of making pure/direct calls into Python require an extra word of typing.  Two birds, one stone.

Thanks,
Jon


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