> On 20 Nov 2017, at 12:34, Brent Royal-Gordon <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. > > Leaving aside those technicalities, it's pretty clear that `foo.bar` should > access a method, not an instance variable, 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. > Bottom line: Ruby cannot be bridged naturally with just an undifferentiated > "access member" hook. It needs separate "access property" and "access method" > hooks. > > -- > Brent Royal-Gordon > Architechies >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
