> On Nov 20, 2017, at 7:08 AM, David Hart via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>
>> On 20 Nov 2017, at 12:34, Brent Royal-Gordon <br...@architechies.com
>> <mailto:br...@architechies.com>> wrote:
>>
>>> On Nov 20, 2017, at 12:32 AM, David Waite via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>>> On Nov 20, 2017, at 1:16 AM, David Hart via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>
>>> <snip>
>>>
>>>> Moreover, Ruby allows classes to have instance variables with the same
>>>> name as methods:
>>>>
>>>> class Foo
>>>> def initialize()
>>>> @bar = 5
>>>> end
>>>>
>>>> def bar()
>>>> puts “Hello"
>>>> end
>>>> end
>>>>
>>>> In that case, how would one implement DynamicMemberLookupProtocol for the
>>>> lookup of bar, and what would the return value be? Its entirely context
>>>> sensitive.
>>>
>>> I do not believe Ruby does not give you direct external access to
>>> variables. Everything with a ‘.’ is a function call.
>>>
>>> You would use e.g.
>>>
>>> Foo.new.instance_variable_get("@bar”) // => 5
>>>
>>> attr :bar exposes a variable @bar through functions bar() and bar=() (and
>>> also optimizes storage in some implementations)
>>
>> This is correct…sort of. Ruby uses symbols to refer to both methods and
>> instance variables, but instance variable symbols always start with @, so
>> they effectively belong to a different namespace. (Similarly, symbols
>> starting with a capital letter are for constants; symbols starting with @@
>> are for class variables; I believe symbols starting with $ are for global
>> variables.) Ruby only provides syntax to access another object's methods and
>> (for a class) constants, so in practice there's no way to access another
>> object's instance variables except by calling a method on it, but there's no
>> particular reason our bridge would need to follow that rule.
Just to add a little weight to what Brent wrote here: in Ruby, one can •only•
access instance variables of self using the @bar syntax. There is no such thing
as “foo.@bar”; as Brent wrote, one can only access another object — not even
another class, but another object! — via its methods.
Class authors thus expect @bar to be private (well, same-instance protected),
and instance_variable_get/set is the accepted in-Ruby hack to fiddle with
another object’s internal state. I see no reason a bridge would need to deviate
from that understanding.
>>
>> Leaving aside those technicalities, it's pretty clear that `foo.bar` should
>> access a method, not an instance variabl, when `foo` is a Ruby object. That
>> doesn't mean it's the same as Python, though, because in Ruby it will need
>> to *call* the method immediately if we're to provide natural syntax for Ruby
>> objects bridged to Swift.
>
> Exactly. My example was a bit contrived but that’s what I wanted to say.
X-ref to a thread where we discussed this at greater length:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171113/041447.html
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171113/041447.html>
Cheers,
Paul
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
