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

[Jean-Daniel]

> Le 18 nov. 2017 à 17:13, Paul Cantrell via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 
>> On Nov 18, 2017, at 1:44 AM, Jean-Daniel <mailing at xenonium.com <mailto:mailing at xenonium.com>> wrote:
>> 
>> 
>>> …
>>> 
>>> In Ruby, `myObj.name()` is equivalent to `myObj.name`, and either works. In Swift, I don’t see that it’s possible to make both work with Chris’s proposal.
>> 
>> IIUC, the goal is not to make swift look and behave the same as ruby or python, but to be able to use ruby or python object in a swift way (without indirect call and other nasty constructions). I don’t see requiring the .property syntax and prohibiting the .property() one as an issue. I would even say this is the thing to do, as it would make the swift code more understandable to Swift dev that are not used to Ruby.
> 
> 
> It really wouldn’t. 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 look like Swift even when bridging to Ruby, then the bridge needs to support both access forms.
> 
> Cheers, P

It’s unfortunate that we can’t know what is a property and what is a method, but if we can’t tell them appart, supporting both form seems reasonable.

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