> On Nov 20, 2017, at 12:50 PM, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: > > > >> On 20 Nov 2017, at 21:10, Chris Lattner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Nov 20, 2017, at 10:50 AM, Slava Pestov via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> >>> >>>> On Nov 20, 2017, at 1:39 PM, Chris Lattner via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> It is straight-forward (and fits very very naturally into the Swift call >>>> model) to support the second one as an atomic thing, which is I think what >>>> you’re getting at. >>> >>> What if you write ‘let fn = obj.method’? >> >> That’s related to the DynamicMemberLookup proposal. I’m not familiar with >> Ruby, but it sounds like the implementation would end up calling >> rb_iv_get/set to manipulate instance variables. Is that your question or >> are you asking something else? > > I don’t think that’s what he is asking. If `method` is indeed a method, then > `obj.method` in Ruby would return the method as a `Proc` (If I’m not > mistaken), ready to be called, very similarly to how it works in Swift: > > class Foo { > func bar(_ a: String) { > print(a) > } > } > > let foo = Foo() > let b = foo.bar > b()
I’m not going to speculate what Slava meant (please speak up!), but given David Waite’s recent email, it isn’t clear that we’d want to provide this. It seems reasonable for a Ruby interop layer to implement the DynamicCallable (in method only form?) but not DynamicMemberLookup. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
