> On Nov 20, 2017, at 6:06 PM, Paul Cantrell <cantr...@pobox.com> wrote:
>>
>> I think you’re missing the idea here: the idea isn’t to provide exactly
>> syntax mapping of Ruby (or Python) into Swift, it is to expose the
>> underlying semantic concepts in terms of Swift’s syntax. In the case of
>> Python, there is a lot of direct overlap, but there is also some places
>> where Swift and Python differs (e.g. Python slicing syntax vs Swift ranges).
>> In my opinion, Swift syntax wins here, we shouldn’t try to ape a non-native
>> syntax in Swift.
>>
>>> For mapping to Swift, I would say that parens are needed; we can’t guess
>>> whether a `foo.bar` is meant to be asking for the value of attribute bar or
>>> a reference to method bar.
>>
>> +1
>
> Chris, did you follow at all the earlier chain of emails where Brent,
> Jean-Daniel and I hashed this out at length? You may not have got to it yet….
Perhaps not, I’m just catching up on this thread now. Keep in mind I know
almost nothing about Ruby :-)
> 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.
> 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!
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
