Re: Translating KVO-ed property to Swift
Re: Translating KVO-ed property to Swift
- Subject: Re: Translating KVO-ed property to Swift
- From: Richard Charles <email@hidden>
- Date: Mon, 24 Apr 2017 09:07:59 -0600
> On Apr 23, 2017, at 11:27 AM, Charles Srstka <email@hidden> wrote:
>
>> On Apr 20, 2017, at 3:06 PM, Quincey Morris <email@hidden> wrote:
>>
>> Where I disagree is in your much stronger claim that a computed property is *necessarily* a dependent property. I think this is just false. The Swift distinction between computed and stored properties is syntactic and has nothing to do with KVO**. A KVO-observed computed property should therefore, according to the documented principle, be marked “dynamic”. For anyone following your extended principle, if it’s also a dependent property, they can omit the “dynamic”. If not, not.
>
> Do you have any example of a property not backed by anything where KVO even makes sense? The whole purpose of KVO is to watch changes to values, and if there’s no value, it seems like the wrong tool.
I have a property that returns an array. A setter for this property makes no sense. The property returns a collection of managed objects that is the composite value of several to-many relationships.
This property is KVO compliant and bound to the NSContentArrayBinding of an array controller.
There is most likely more than one way to do this but I find using bindings convienient. You can bind to a KVO compliant property. You can't bind to a notification.
This is in an Objective-C project that requires interoperability with a C++ library. So using Swift is not possible but maybe someday it will be.
--Richard Charles
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden