> On May 27, 2016, at 9:22 AM, Anders Ha <[email protected]> wrote: > >> >> On 27 May 2016, at 9:30 PM, Matthew Johnson <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> Sent from my iPad >> >> On May 27, 2016, at 5:45 AM, Anders Ha via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> I wonder how the views would work with the value semantic of structs. >> >> Not all value types have value semantics. It's important to not forget >> that. I would like to see a way to make that distinction clear in our code >> but that is a conversation for another thread. > > I meant value types. Thanks for pointing out that. :-) > >> >>> >>> The view types proposed, if not being a compiler magic, would need to have >>> a reference to the reflected instance. They are also escapable unless >>> special rules for the view types are enforced. So… perhaps we would want >>> less magic and special rules? >>> >>> IMO these views are not necessary, and can be consolidated into >>> typed/untyped get/set calls on `Reflectable`. However, if the intention is >>> to amortize the type metadata lookup, or not to introduce any kind of >>> lookup caching in the runtime, perhaps we can introduce instead property >>> descriptors. >>> >>> (A quick dump of my idea: >>> https://gist.github.com/andersio/9ff02257b5c89b35fd523dcd09e484e4 >>> <https://gist.github.com/andersio/9ff02257b5c89b35fd523dcd09e484e4>) >> >> Property descriptors could be useful in the sense that they wouldn't need to >> refer back to the instance. But I would also like to see a way to get >> something like a lens into the property for a specific instance which is >> what the views allow for. This design doesn't allow for that. Maybe we >> want to allow you to query for property descriptors alone, lenses alone, or >> the combination in a view. >> > > Just for the record, I was meaning that the user can request a typed > descriptor of a particular named instance properties (and even class > properties) at runtime from the metatype. Users may then use these typed > descriptors to query or modify the value from a specific instance. > > It is like KVC, but uses typed descriptors instead of string key paths.
I understand this. But this is not like a lens. It is much more awkward to use. > > Anyway, the most important message I'd like to raise is that the mutation > should be acted upon the owner of the property, if the reflection is supposed > to cover also value types. > > Specifically using Zheng’s initial idea as an example, the setter in > “GetSetPropertyView” of a property in a struct instance should not cause any > change to the original instance by the established behaviour of value types > in Swift. > > Let’s say even If there are some kind of pointer magic bypassing the value > type restrictions at runtime, GetSetPropertyView cannot be escaped but only > useable in the local scope. Otherwise, we would have a view that can somehow > point to nothing. This doesn’t sound great either way. > You raise good points here. I am interested to hear what Joe Groff has to say about this. I believe the issues involved are the same as those involved with lenses into value types. > >>> >>> >>> Best Regards >>> Anders >>> >>> >>>> On 27 May 2016, at 9:25 AM, Austin Zheng via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> Hi swift-evolution, >>>> >>>> For those who are interested I'd like to present a pre-pre-proposal for >>>> reflection upon a type's properties and solicit feedback. >>>> >>>> First of all, some caveats: this is only a very small piece of what >>>> reflection in Swift might look like one day, and it's certainly not the >>>> only possible design for such a feature. Reflection comes in many >>>> different forms, and "no reflection" is also an option. Deciding what sort >>>> of reflection capabilities Swift should support is a prerequisite to >>>> stabilizing the runtime API, which I imagine has resilience consequences. >>>> I'm not really interested in defending this specific proposal per se, as I >>>> am looking for a jumping-off point to explore designs in this space. >>>> >>>> Anyways, here is a gist outlining the public API to the feature: >>>> >>>> https://gist.github.com/austinzheng/699d47f50899b88645f56964c0b7109a >>>> <https://gist.github.com/austinzheng/699d47f50899b88645f56964c0b7109a> >>>> >>>> A couple of notes regarding the proposal: >>>> >>>> The API names need improvement. Suggestions welcome. >>>> >>>> It's opt-in: types have to conform to a special protocol for the compiler >>>> to generate whatever hooks, metadata, and support code is necessary. Once >>>> a type conforms, the interface to the reflection features naturally >>>> present themselves as protocol methods. It would be great to allow an >>>> extension to retroactively enable reflection on a type vended by another >>>> module, although I have no idea how feasible that is. >>>> >>>> It uses "views": there are four types of views, two of each in the >>>> following categories: typed vs untyped, get-only versus get-set. A view is >>>> a struct representing a property on an instance of a type (or maybe a >>>> metatype, for type properties). It allows you to get information about >>>> that property (like its name) and try getting and setting its values. >>>> >>>> (You can get a get-only view to a property, and then try and upgrade it >>>> later to a get-set view, if the underlying property is get-set. If you >>>> don't care about setting, though, you can just work exclusively with >>>> get-only views.) >>>> >>>> It supports both typed and untyped access. You can ask for a property view >>>> specifically for (e.g.) a `String` property, and if you get one you can be >>>> assured that your getting and setting operations will be type safe. You >>>> can also ask for an "untyped" property view that exposes the value as an >>>> Any, and allows you to try (and possibly fail, with a thrown error) to set >>>> the value. >>>> >>>> The requirements part of it is composable. For example, you can imagine a >>>> future "FullyReflectable" protocol that simply inherits from >>>> "PropertyReflectable", "MethodReflectable", and other reflectable >>>> protocols. Or maybe a library requires reflection access to types that it >>>> needs to work with, and it can create its own protocols that inherit from >>>> "PropertyReflectable" and naturally enforce reflection support on the >>>> necessary types. >>>> >>>> It looks a bit cumbersome, but there's room for refinement. Users won't >>>> necessarily see all the types, though, and the interface is pretty >>>> straightforward: >>>> >>>> ``` >>>> myPerson.typedReadWriteProperty<Int>("age")?.set(30) >>>> >>>> try myPerson.allNamedProperties["age"]?.set(30) >>>> ``` >>>> >>>> I'm not yet sure how it should interact with access control (my >>>> inclination is that it would only expose the properties you'd be able to >>>> directly access), or property behaviors (I think get-set behavior is >>>> fundamental to properties, although "behavior metadata" on the views might >>>> be useful). >>>> >>>> I'd also have to figure out how it would operate with generic types or >>>> existentials. >>>> >>>> Anyways, thanks for reading all the way to the end, and any feedback, >>>> criticism, or alternative proposals would be greatly appreciated. >>>> >>>> Best, >>>> Austin >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
