> On Nov 28, 2017, at 10:54 PM, Chris Lattner <clatt...@nondot.org> wrote:
>
>> On Nov 28, 2017, at 10:12 AM, Paul Cantrell <cantr...@pobox.com
>> <mailto:cantr...@pobox.com>> wrote:
>> Chris wrote:
>>> Paul wrote:
>>>> 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.
>>>
>>> Ok, that can certainly be implemented by the two proposals I have in
>>> flight. No obvious problem there.
>>
>>
>> Chris, can you elaborate? I think the proposal precludes this; I must be
>> missing something!
>
> There are two proposals in flight: one that allows specifying runtime
> behavior for “a.b” syntax and one that allows specifying runtime behavior for
> “a(x)” and “a.b(x)” syntax (“DynamicCallableWithKeywordsToo”, which needs to
> be renamed obviously).
Yes, I’m aware of the two proposals in flight, but apparently missed the
updated DynamicCallable proposal.
You must be talking about DynamicCallableKeywordedMethod, not
DynamicCallableWithKeywordsToo? Yes, that third protocol would solve the
problem!
Is DynamicCallableKeywordedMethod an official part of the callable proposal? I
was thrown by the fact that the “Smalltalk Family Languages” section is not
nested under “Proposed Solution,” and thought it was meant as a
separate/alternative idea. But reading the text, I see that it does seem to be
part of that proposal.
If that’s correct, then that “Smalltalk family” section ought to clarify that
DynamicCallableKeywordedMethod takes precedence over
DynamicMemberLookupProtocol. In other words, if `a` implements both protocols,
then this:
a.b(x)
…expands to this:
a.dynamicCall(method: "b", arguments: [("", x)])
…and not this:
a[dynamicMember: "b"].dynamicCall(arguments: [("", x)])
…while this:
a.b
…still expands to:
a[dynamicMember: "b”]
Cheers, P
> For your use case, you’d implement both of them. If someone wrote
>
> a.b().c
>
> Then you’d look up and call a zero-argument method named “b” on the a object.
> However if someone wrote:
>
> a.b.c
>
> Then you’d do the same thing (in the implementation of the
> DynamicMemberLookupProtocol). This approach allows the human writing code at
> your bridge to use whatever syntax “feels best” to them given the specific
> API in question that they are using.
>
> You could even have “a.b” syntax fall back to finding Ruby ivars as well,
> though I don’t know if that is actually a good idea in practice for a Ruby
> bridge.
It’s certainly not the behavior you’d want, no. Ruby devs make a clear
distinction between attr readers (Ruby’s name for properties) and ivars (which
are same-instance-private).
>
>> As I read the proposal, the dynamic member subscript for post.author returns
>> either a property value or a DynamicCallable, depending on whether the thing
>> is a property or a method — but post.author and post.author() would both
>> look identical to that subscript implementation, and there’s no distinction
>> on the Ruby side, so the subscript can’t know which one to return.
>
> “post.author" always invokes the DynamicMemberLookupProtocol proposal.
> “post.author()” would invoke the “DynamicCallableWithKeywordsToo” hook in the
> dynamic callable proposal:
> https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d
> <https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d>
>
> -Chris
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
