On Apr 24, 2017, at 10:11 , Charles Srstka <cocoa...@charlessoft.com> wrote: > > What Quincey seemed to be referring to was a property that was not backed by > any kind of persistent value.
That wasn’t actually the kind of property I had in mind. I was thinking of settable, computed properties that did not depend on the value(s) of other KVO-observable properties. There probably aren’t many plausible *simple* examples, but I was thinking of such cases as when the value is stored in an I/O device rather than RAM, or when the value is retrieved from a server. One problem with such examples, though, is that it’s not clear in the abstract whether you would keep a stored (RAM) value as well. Another problem I’ve been brooding over is whether a property (stored or computed) that has KVO dependencies can actually be regarded as a dependent property *if it has a setter*. Depending on the details, I suspect, the property could be regarded as fully dependent, partially dependent, not dependent, or not classifiable. Separately, I’ve been brooding over the kinds of audiences that might need advice (advisories) about using “dynamic”. I think there’s a large fraction of the developer population, perhaps a majority, who aren’t aware of the details of how KVO notifications are implemented, and an explanation is just a distraction that’s more confusing than enlightening. (For any one developer, that can change over time, of course.) This makes me think that there need to be two rules, one simple and one advanced, for two different audiences. The simple rule applies when you allow Cocoa to generate KVO notifications automatically (when setters are called or when you use “keyPathsForValuesAffecting<Key>”), but in deference to Charles’ concerns isn’t quite as simple as what the documentation says. It’s now this: > Add the “dynamic” keyword if the property has a setter. This covers the cases where “dynamic” is absolutely required (independent properties), and it covers all dependent properties without a setter (which, in practice, is most of them). It *might* add an unnecessary “dynamic” to a computed property with a setter, but I really think it’s the safest solution in such cases. The advanced rule goes something like this: > For any property with a setter, if you generate notifications manually via > willSet/didSet, and you don’t need or want automatic notifications produced > by the setter, you must implement “automaticallyNotifiesObserversOf<Key>” to > return ‘false’, and the property doesn’t need the “dynamic” keyword. > Otherwise, add “dynamic” if there is a setter. That is (I hope/intend) exactly equivalent to what Charles has being saying. _______________________________________________ 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
