Re: Translating KVO-ed property to Swift
Re: Translating KVO-ed property to Swift
- Subject: Re: Translating KVO-ed property to Swift
- From: Jean-Daniel <email@hidden>
- Date: Thu, 20 Apr 2017 23:12:30 +0200
Just a tough that go in the ‘always use dynamic’ side. I think setter interposition is not the only issue with KVO. KVO also need to be able to fetch the old property value when -willChange: is called. I’m not sure about how it does that, but I’m pretty confident it will break if the getter is not properly exposed in Obj-C, which may be the case if the property is neither declare @objc, nor dynamic.
> Le 20 avr. 2017 à 22:06, Quincey Morris <email@hidden> a écrit :
>
> On Apr 20, 2017, at 10:24 , Charles Srstka <email@hidden> wrote:
>>
>> I mean, yes, we could go all the way down to explaining how everything works in terms of the physics and chemistry of electrons and semiconductors, but that wouldn’t be very practical, would it?
>
> I subscribe to the principle already quoted from the documentation: If you KVO-observe a property, mark it “dynamic”. I like this because it is simple and unambiguous. If anyone asked me for advice, I’d say to follow this principle and don’t agonize any further.
>
> As a different discussion, at a different level, I agree that there are scenarios where you can omit “dynamic” and still get all the KVO notifications you wanted. What scenarios? Well, I think the essence of your argument is that it can be omitted for a KVO-observed *dependent* property. That at least sounds pretty plausible to me, and it may even be true by definition. If anyone asked you for advice, then I guess you’d say to accept this as an extension of the documented principle. Me, I’m not 100% certain about this, if for no other reason than the documented principle is future-proof against a change in the way things work where Apple says, “Well, we told to you mark all KVO-observed properties dynamic.” But, people can go for advice where they want.
>
> 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.
>
>
> ** Indeed, it’s trivially easy to convert a public stored property into a public computed property that uses a private, stored, non-KVO-observed property as its instance storage.
>
> _______________________________________________
>
> 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
_______________________________________________
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