Re: Translating KVO-ed property to Swift
Re: Translating KVO-ed property to Swift
- Subject: Re: Translating KVO-ed property to Swift
- From: Charles Srstka <email@hidden>
- Date: Mon, 24 Apr 2017 12:11:03 -0500
> On Apr 24, 2017, at 10:07 AM, Richard Charles <email@hidden> wrote:
>
>>
>> On Apr 23, 2017, at 11:27 AM, Charles Srstka <email@hidden <mailto:email@hidden>> wrote:
>>
>>> On Apr 20, 2017, at 3:06 PM, Quincey Morris <email@hidden <mailto: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
But it sounds like this property *is* backed by a value. The backing is the collection of managed objects. I take it you’re simply watching changes to the C++ source data and calling didChange/willChange when appropriate—basically translating one type of notification to another. This makes perfect sense—although not having a setter, being marked ‘dynamic’ would not change its behavior at all.
What Quincey seemed to be referring to was a property that was not backed by any kind of persistent value. Presumably, this property would also have a setter, since otherwise ‘dynamic’ isn’t really in play. I’m very curious as to what the applicability of such a thing would be, because I can’t think of any myself.
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