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

[Chris Lattner]

> On Nov 15, 2017, at 10:00 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>> On Nov 14, 2017, at 11:29 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> extension PyVal {
>>   subscript(dynamicMember member: String) -> PyVal {
>>     get {
>>       let result = PyObject_GetAttrString(borrowedPyObject, member)!
>>       return PyRef(owned: result)  // PyObject_GetAttrString returns +1 result.
>>     }
>>     set {
>>       PyObject_SetAttrString(borrowedPyObject, member,
>>                              newValue.toPython().borrowedPyObject)
>>     }
>>   }
>> }
> 
> This looks great for Python, but let's talk about some other languages for a moment.
> 
> * Ruby and Perl don't have the "call a method by fetching a closure property and invoking it" behavior you're relying on here. Instead, Ruby has a syntax for settable "overloads" of methods (i.e. you can write `def someMember` and `def someMember= (newValue)`), while Perl supports lvalue methods (but sometimes uses getter and setter method pairs instead). How do you envision these behaviors being bridged to Swift? I worry that this protocol may not be sufficient, and that we may need a design which can distinguish between looking up methods and looking up properties.

I’m not sure without more description, but it seems like these are both general property models which can be implemented with this protocol as is.  The getter would call someMember, and the setter would call someMember=.  What complication are you anticipating?


> * Ruby looks up members using symbols, which essentially play the same role as selectors in Objective-C—they're uniqued strings which are used for fast member dispatch. In some cases, you might see non-negligible speed improvements by only looking up the symbol once. Is there a way this design could accommodate that? 

Yes, I think that this is very much in scope for the DynamicCallable proposal.  We talked about this in the context of Squeak (another smalltalky language), and it fits naturally with the design.  I’ll add that when I have time to revise the pitch.

> * Generally, you've talked about properties (in this proposal) and methods (in the `DynamicCallable` proposal), but what about subscripts? Obviously you can just specify a `subscript(Pythonable) -> PyVal` on `PyVal` for the simple case, but what if the subscript takes multiple indices or has labels? Do we need a `DynamicSubscriptable` protocol?

Subscripts can already be varargs, so the only reason we’d need a DynamicSubscriptable proposal is if there were another language that allowed keywords on subscript indices.  If so, then yes, we’d need that.

> * Let's step away from bridging entirely and just think about Swift for a moment.  There are cases where we'd like to make *semi*-dynamic proxies which wrap another type and allow operations based on what's statically known about that type. Think, for example, of the appearance proxy in UIKit: This is an object attached to UIView subclasses which lets you (in essence) set default values for all instances. We currently just pretend it's an instance of `Self`, which mostly works because of Objective-C, but a Swift-native version would probably prefer to return a `UIAppearance<Self>` object which used its knowledge of `Self` to expose `Self`'s properties on itself. Is there a way we could design this feature, or a related feature, to cover that kind of use case? That is, to allow a limited set of keys—perhaps even key-path-based when you want static control—with a different type for each key, *or* to allow any key with some common type, depending on your type's needs?

I wouldn’t be at all surprised if this was possible, but given that this type erases everything that goes through the proxy, and given that it doesn’t provide type checking, it isn’t clear to me that you’d get a really great answer.

> * Actually, for that matter, let's talk about key paths. In principle, you can already think of member lookup in Swift—or at least property and subscript lookup—as though it always worked by constructing a key path and using `subscript(keyPath:)` to access it. Is there some way we could model this feature as extending the set of keys available on a given type—perhaps in a way that allowed compile-time-limited and strongly-typed sets of keys, like I mention with the `UIAppearance` example, in addition to the open-ended, type-erased sets you need—and then looking things up by key path? (Sorry if this is a little vague—I know very little about how key paths are implemented.)

I don’t know.

> * An implementation-level question about Swift: Internally, the compiler seems to be moving towards thinking of parameter labels as part of the identifier, rather than having them label the individual arguments. How do you see that jibing with what you're proposing here?

This is part of the DynamicCallable proposal that I will be revising as mentioned above, it isn’t related to the member lookup side of the equation.

-Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171120/3889177a/attachment.html>