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. -----Original Message----- From: "Brent Royal-Gordon via swift-evolution" <swift-evolution@swift.org> Sent: 27/05/2016 07:25 AM To: "Matthew Johnson" <matt...@anandabits.com> Cc: "swift-evolution" <swift-evolution@swift.org> 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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
