[swift-evolution] [Pitch] Property reflection
brent at architechies.com
Fri May 27 05:25:15 CDT 2016
> 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.
More information about the swift-evolution