I’m not sure this solves the Ruby ergonomics problem. Picking up from an
earlier thread:
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!
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.
The getter could return something that is both a dynamic callable and has
dynamic members that lazily make the implicit method call. But this has two
serious problems:
1. The necessarily lazy evaluation of the property value leads to nightmare
scenarios:
post.author = sally
let oldAuthor = post.author()
post.author = fred
oldAuthor.name // "Sally"
// but
post.author = sally
let oldAuthor = post.author
post.author = fred
oldAuthor.name // "Fred"
2. This precludes bridging to Swift types, e.g. Ruby strings → Swift strings.
Therefore it seems the proposal forces post.author().name().reverse().
Something I'm missing?
Cheers,
Paul
> On Nov 27, 2017, at 12:04 AM, Chris Lattner via swift-evolution
> <[email protected]> wrote:
>
> I’d like to formally propose the inclusion of user-defined dynamic member
> lookup types.
>
> Here is my latest draft of the proposal:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
> https://github.com/apple/swift-evolution/pull/768
>
> An implementation of this design is available here:
> https://github.com/apple/swift/pull/13076
>
> The implementation is straight-forward and (IMO) non-invasive in the compiler.
>
> -Chris
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
