Sent from my iPad
> On May 27, 2016, at 6:15 AM, Leonardo Pessoa <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
