> On Nov 14, 2017, at 11:29 PM, Chris Lattner via swift-evolution
> <swift-evolution@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.
* 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? For instance, could the type of the index be specified by an associated
type, so Ruby could use a RbSymbol instead of a String? Or do you think that
would be overkill?
* 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?
* 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?
* 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.)
* 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?
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
