> On Apr 23, 2017, at 11:27 AM, Charles Srstka <cocoa...@charlessoft.com> wrote: > >> On Apr 20, 2017, at 3:06 PM, Quincey Morris >> <quinceymor...@rivergatesoftware.com> 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 _______________________________________________ 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
