[swift-evolution] [Pitch] Property reflection

[Matthew Johnson]

Sent from my iPad

> On May 27, 2016, at 6:15 AM, Leonardo Pessoa <me at lmpessoa.com> wrote:
> 
> I'm also not fond of allowing what could be called a backdoor to accessing privates and intervals too but has anyone thought of enhancing the Mirror class instead of having something totally new? I've tried using it once but in the end it wasn't necessary for what I needed to do.
> 
> An opt-in into reflection would be interesting too as it could help remove the burden of the compiler to prepare each class and instance for reflection. Should a type be prepared for reflection one could add to it an attribute like @reflected. Then the compiler would add the necessary optimisations to it and its subclasses.
> 
> About serialisation, I still think the best way to deal with it is to use the Visitor pattern. Each class that needs serialisation implements the functions that say what exactly is needed to save and restore state. I don't see how anything automatic can be better than this.

I brought up serialization because a lot of people *want* to do it using a dynamic API.  This is a part of the Objective-C vs Swift dynamism conversation that is happening right now.  That conversation inspired Austin's pitch and also my comment that people's desire for this makes access control a tricky issue.

Regardless of *you* want to do serialization, I think it's important to recognize that this is a hot topic and one of the frustrations some people currently have with Swift.  I think it's worth having the conversation about how we can better satisfy the use cases they have talked about and what role reflection might play in that.

I think most serialization use cases are probably better served by static rather than dynamic reflection.  But it isn't clear how long we'll have to wait until we can do that.

> From: Brent Royal-Gordon via swift-evolution
> Sent: ‎27/‎05/‎2016 07:25 AM
> To: Matthew Johnson
> Cc: swift-evolution
> Subject: Re: [swift-evolution] [Pitch] Property reflection
> 
> > 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.
> 
> I had some thoughts about an alternate design based partially on access control concerns. Sketching roughly, it looks like this:
> 
> * There is a pseudo-property called, say, `properties` on every type (and perhaps on every instance). (Alternate designs are available, like an `inout`-returning pseudo-function. It doesn't really matter.)
> 
> * `properties` is a dictionary, or at least something very like a dictionary: you can look something up by key or iterate over the available keys. Its keys are strings, and its values are lens functions. These lens functions return type Any; their setters throw if you assign an incompatible type.
> 
> * The contents of `properties` are the properties visible *at the site where it is called*. That means calling `properties` in different places will give you different results. If you import a type from another module and then add properties in an `internal` extension, you'll see the other module's `public` properties plus your `internal` ones.
> 
> * You can pass your `properties` dictionary to other code; that effectively delegates your access to that other code. Thus, if your main class body passes its `property` dictionary to a serialization library, that library can access your private properties. If you pass it `inout`, then the library can modify your private properties.
> 
> * There is no opting in, but I *think* the compiler has enough information to figure out what goes into `properties` at the sites where it is used, so you only have to pay for it if and when you use it. I could be wrong, though—there may be something there that I'm missing.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160527/48868a2c/attachment.html>