I'm talking of model objects that serializes certain properties (not
necessarily all) that should have their setter be private/hidden for
encapsulation reasons:
struct Person {
private(set) var birthdate: NSDate
}
I'm not a fan of adding an attribute like private(reflectable). The proposal we
are discussing is most probably coming post-Swift3 and we might as well wait
until property behaviour a are brought in to the mix.
Sorry if my post feels negative, but I'm a huge supporter of Reflection APIs
and I just want us to get it right :)
> On 27 May 2016, at 09:25, Austin Zheng <austinzh...@gmail.com> 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...
>
> Austin
>
>
>> On May 26, 2016, at 11:52 PM, David Hart <da...@hartbit.com> wrote:
>>
>>
>>
>>> On 27 May 2016, at 04:44, Austin Zheng via swift-evolution
>>> <swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
