Sorry I didn’t get around to replying sooner; I’ve had a busy past few days.
> On Apr 20, 2017, at 3:06 PM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On Apr 20, 2017, at 10:24 , Charles Srstka <cocoa...@charlessoft.com > <mailto: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. It is simple, and it’ll work, and there’s certainly nothing wrong with it. It’s a little non-ideal performance-wise, though, which is why I prefer using dynamic only where it’s needed. > 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. The essence of my argument is pretty simple; it can be omitted for any property where willChange and didChange are already being called. For a dependent property, those calls will be made in your dependency, so you don’t need dynamic. For a stored property where you’re calling willChange and didChange yourself, you don’t need dynamic. For, I dunno, weird situations where willChange and didChange are getting called somewhere else but at the appropriate times, you don’t need dynamic. Dynamic is only needed to let Cocoa add the willChange and didChange notifications for you. > 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. This isn’t just based on empirical observation, though; it’s based on the documentation of the KVO mechanism, which predates Swift by quite a lot. KVO isn’t a mysterious black box; the details of it are all available in the documentation, and once you understand them, you understand *why* dynamic is needed. And once you understand *why* it’s needed, you also will understand *where* it’s needed. Personally, I prefer to, when possible, understand the reasons behind doing things rather than repeating magical incantations. As for future-proof, I fully expect that in some future version of Swift (Swift 5, hopefully, maybe Swift 6), we’ll get a new and improved, Swift-native replacement for KVC and KVO and we’ll all be ripping out our existing KVO code in favor of that anyway. > 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 mean, sure, I could make this observable: var whyWouldIObserveThis: Int { return Int(arc4random()) } and then send didChange/willChange notifications on a timer or something. But... *why?* Charles _______________________________________________ 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
