Sent from my iPad
> On May 26, 2016, at 9:44 PM, Austin Zheng <[email protected]> wrote: > > Thanks, as always, for the thoughtful feedback. (inline) > >> On Thu, May 26, 2016 at 7:20 PM, Matthew Johnson <[email protected]> >> wrote: >> >> >> These names are a good place to start but I agree that it would be nice to >> improve them. I will give it some thought. One comment for now - you use >> both `get` / `set` and `read` / `write`. It’s probably better to pick one. > > Yes, that's a good start. I'll sleep on it. > >> >>> >>> 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. >> >> What do you think of using the `deriving` syntax for this (assuming we go in >> that direction for Equatable, Hashable, and other synthesized conformances). > > 'deriving' is pretty much what I had in mind. If Equatable gets a magical > attribute, keyword, or whatever, I'd like to use it for this feature as well. > >> >>> >>> 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. >> >> How did you arrive at `get` and `set` methods? > > One big advantage methods have over properties is that you can (as of right > now) get a reference to a method as a value of function type, but not a > property. True, but as with 'throws' this is a temporary limitation. I don't think we should design our reflection API around a temporary limitation. IIRC the intended plan for getting first class access to properties is a lens. If we model it as a property we will eventually get first class access to it as a lens (which means we play nice with lenses even though we don't know what they will look like yet). > >> >> I am wondering how this might relate to lenses. If we’re going to introduce >> those it feels like the property value should be introduced as a lens. I’m >> unsure of exactly what that would look like but I it is definitely worth >> thinking about. > > I think it's worth consideration. Maybe views into properties can eventually > conform to some sort of lens protocol or interface, allowing them to be > composed and used as such. I think Joe Groff has talked about lenses more than anyone else. Maybe he has some thoughts on this. But as I noted above, maybe exposing access as a property is the best first step. It's easy enough to wrap in a closure if you need to pass a function around before property references / lenses are introduced. > >> >> Another option if we don’t go with a lens is a simple property (`var value { >> get }` and `var value { get set }`). IIRC we are going to have throwing >> computed properties eventually so you could still throw from the setter. >> >>> ``` >>> >>> 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), >> >> This one is tricky. I am generally be opposed to any way to get around >> access control. But people are going to implement things like serialization >> using this which may require access to private properties. I think we want >> to try to understand the consequences of different options and when in doubt >> decide in favor caution. > > My personal preference would be to honor access control, and consider ser/de > separately (especially since there are so many other possible considerations > for that feature). Access control in Swift isn't just another safety feature, > it's also a boundary for things like the optimizer. > > To be honest, I expect the first big use of a feature like this to be turning > JSON or XML received from a network call into model objects for an app. There > are quite a few Objective-C libraries that use KVC to implement this > functionality. As several have noted, this is what makes things tricky. People will want to write a library packaged as a module that can serialize private properties from types in a different module. We need to at least consider that use case. Supporting reflection-specific visibility might be a reasonable way to strike a balance. But I'm sure it would also receive a lot of resistance on both sides (those who don't think it's necessary to make internals more visible and those who want them to be visible without extra boilerplate). > >> >>> or property behaviors (I think get-set behavior is fundamental to >>> properties, although "behavior metadata" on the views might be useful). >> >> Not just behavior metadata. Someday we might have user-defined attributes >> which we would also want to have available. It’s probably better to make >> available anything that could be useful and isn’t too costly to provide. It >> could all live behind a `metadata` property so we don’t clutter the >> interface of the views themselves. > > Absolutely. It's not clear right now what property behaviors will end up > looking like, but if possible I'd definitely like to reify them and expose > them to the end user (like how the T.Type is exposed in the gist). At the > very least (and this is definitely insufficient), there should be a list of > strings describing the behaviors. >>> >>> 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] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
