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 <quinceymor...@rivergatesoftware.com> > a écrit : > > On Apr 20, 2017, at 10:24 , Charles Srstka <cocoa...@charlessoft.com> 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 (Cocoa-dev@lists.apple.com) > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/mailing%40xenonium.com > > This email sent to mail...@xenonium.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
