Sent from my iPad
> On May 27, 2016, at 2:25 AM, Austin Zheng <[email protected]> wrote: > > Would you be willing to elaborate? Are you thinking of model objects whose > properties are all completely hidden using 'private' and whose APIs are > available only through methods? What if there existed something like > "private(reflectable)", for properties you really want to keep both private > and exposed to the reflection machinery? Or maybe a property behavior to do > the same thing once that feature becomes a reality... 'private(reflectable)' would mean private for the purpose of reflection if we follow the same interpretation as 'private(set)'. Maybe you meant 'private public(reflectable)' - as in private, but public for the purpose of reflection only. > > Austin > > >> On May 26, 2016, at 11:52 PM, David Hart <[email protected]> wrote: >> >> >> >>> On 27 May 2016, at 04:44, Austin Zheng via swift-evolution >>> <[email protected]> wrote: >>> >>> My personal preference would be to honor access control, and consider >>> ser/de separately (especially since there are so many other possible >>> considerations for that feature). Access control in Swift isn't just >>> another safety feature, it's also a boundary for things like the optimizer. >>> >>> To be honest, I expect the first big use of a feature like this to be >>> turning JSON or XML received from a network call into model objects for an >>> app. There are quite a few Objective-C libraries that use KVC to implement >>> this functionality. >> >> That's what I want to use it for and I'm fairly sure we need access to >> private properties for that. > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
