[swift-evolution] [Pitch] Property reflection

[L Mihalkovic]

> On May 27, 2016, at 4:05 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
> Sent from my iPad
> 
> On May 26, 2016, at 9:44 PM, Austin Zheng <austinzheng at gmail.com <mailto:austinzheng at gmail.com>> wrote:
> 
>> Thanks, as always, for the thoughtful feedback. (inline)
>> 
>> On Thu, May 26, 2016 at 7:20 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> 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 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160527/15d4a9e9/attachment.html>