Sent from my iPad
On May 27, 2016, at 5:25 AM, Brent Royal-Gordon <[email protected]> wrote: >> 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. The syntax in your design would be very convenient for sure. I'm not sure how this alternative is related to access control. Austin's proposal could enforce access control in the same way and he mentioned he was inclined to enforce it the same way you are describing. The reason I say it is tricky is because enforcing access control in this way would prevent things people want to do with reflection (things that have received a lot of discussion recently). Allowing a distinct visibility to be specified for reflection might be a way to strike a reasonable balance. Your suggested approach doesn't allow for access to property metadata. Do you have any suggestions on how that would be exposed? What about casting the lens to a typed lens? Would you envision that being supported? I also think we would want a way to access a specific property by name if accessing the whole properties dictionary involved any non-trivial overhead (but maybe it wouldn't have to). > 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
