Sent from my iPad
> On May 27, 2016, at 8:25 AM, Charlie Monroe <[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. > > Not just deserialization, but also for example, if you take upon something > like Swift version of CoreData, some vars may be private, but the framework > will need access to them. Of course, this could be handled by some annotation > giving access to the variable via reflection. I believe CoreData uses synthesized computed properties that access values stored in an internal row cache (or something along those lines). > > I'm in favor of reflecting all vars by default (even private ones) with an > option to opt-out. I much prefer the opt-in approach if we're going to allow for reflection to have different visibility. Access control should be explicit IMO. > > > >> >>> or property behaviors (I think get-set behavior is fundamental to >>> properties, although "behavior metadata" on the views might be useful). >> >> Not just behavior metadata. Someday we might have user-defined attributes >> which we would also want to have available. It’s probably better to make >> available anything that could be useful and isn’t too costly to provide. It >> could all live behind a `metadata` property so we don’t clutter the >> interface of the views themselves. >> >>> >>> I'd also have to figure out how it would operate with generic types or >>> existentials. >>> >>> Anyways, thanks for reading all the way to the end, and any feedback, >>> criticism, or alternative proposals would be greatly appreciated. >>> >>> Best, >>> Austin >>> _______________________________________________ >>> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
