> On May 27, 2016, at 4:05 PM, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > > > Sent from my iPad > > On May 26, 2016, at 9:44 PM, Austin Zheng <[email protected] > <mailto:[email protected]>> wrote: > >> Thanks, as always, for the thoughtful feedback. (inline) >> >> On Thu, May 26, 2016 at 7:20 PM, Matthew Johnson <[email protected] >> <mailto:[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.
or perhaps simply read what the people who have a lot of experience the topic have to say about it, and hopefully learn from the errors others have described. Serialization has long been a source of serious security issues in Java. Swift could do without these -1
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
