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

[Paul Cantrell]

> On Nov 20, 2017, at 7:47 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Nov 20, 2017, at 1:41 PM, David Waite <david at alkaline-solutions.com> wrote:
>> 
>> In ruby, parens are optional. So,
>> 
>> v = foo.value
>> 
>> and
>> 
>> v = foo.value()
>> 
>> are identical.
> 
> Ok, I wasn’t aware of that.  It isn’t clear that we’d want to carry that into a “Ruby APIs when used in Swift” though!  One could definitely argue against the former calling a method, even if that is possible in Ruby APIs.
> 
>> There dot syntax is only used for method invocation, so there is no external access to instance variables without some twiddling; similarly getting access to a Proc/lambda/Method requires twiddling in Ruby (although there are shortcuts in normal use, like Symbol#to_proc)
> 
> I think you’re missing the idea here: the idea isn’t to provide exactly syntax mapping of Ruby (or Python) into Swift, it is to expose the underlying semantic concepts in terms of Swift’s syntax.  In the case of Python, there is a lot of direct overlap, but there is also some places where Swift and Python differs (e.g. Python slicing syntax vs Swift ranges).  In my opinion, Swift syntax wins here, we shouldn’t try to ape a non-native syntax in Swift.
> 
>> For mapping to Swift, I would say that parens are needed; we can’t guess whether a `foo.bar` is meant to be asking for the value of attribute bar or a reference to method bar.
> 
> +1

Chris, did you follow at all the earlier chain of emails where Brent, Jean-Daniel and I hashed this out at length? You may not have got to it yet….

Key excerpts:

–––––––––––––––––––––––––

An “always use parens” bridge to Ruby has bad ergonomics
Zero-arg Ruby methods are a mixture of property-like things that would certainly not use parens in Swift, and function-like things that certainly would:

    // Idiomatic Swift:
    post.author.name.reversed()

    // Swift bridging to Ruby…

    // …if no-args methods •must• use parens:
    post.author().name().reverse()

    // …if no-args methods •can’t• use parens:
    post.author.name.reverse

If the goal is to make Swift mostly feel like Swift even when bridging to Ruby, then the bridge needs to support both access forms.

–––––––––––––––––––––––––

Separating method calls from property accesses solves the problem

Brent wrote:
> If we had separate subscripts for methods and properties, then the property subscript could immediately call the appropriate getters and setters, while the method subscript could return a ready-to-call `Method` object.


Better yet, why bother with the ready-to-call Method-like object? Just call it! A Ruby binding with separate property and method handling would then look like this:

    extension RubyObj: DynamicMemberLookupProtocol {
      func callDynamicMethod(dynamicMethod method: String, args: [RubyObject]) -> RubyObj {
        get {
          return RubyObject_send(rubyObject, method: member, args: args)
        }
      }
      
      subscript(dynamicMember member: String) -> RubyObj {
        get {
          return RubyObject_send(rubyObject, method: member, args: [])
        }
        set {
          RubyObject_send(rubyObject, method: "\(member)=", args: [newValue])
        }
      }
    }

When Swift sees myObj.name, it uses the getter subscript. When Swift sees myObj.name(), it uses the method invocation. Both work in Swift just as they do in Ruby — and more importantly, Ruby APIs wouldn’t feel so very awkward when used from Swift.


> 
>> More difficult would be the use of ‘=‘, ‘!’, and ‘?’ - all legal in Ruby method names as suffixes.
> 
> Using those would require backquotes:
> 
> x.`what?`() 
> 
> 
> -Chris
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171120/05ea02df/attachment.html>