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

[Chris Lattner]

On Nov 20, 2017, at 6:12 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> 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.
> 
> Right, that should work directly!
> 

I just sent out draft 2 of the DynamicCallable proposal, which directly includes support for this.  Thanks for the discussion and insight!

-Chris

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