> On 18 Nov 2015, at 6:43 PM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > As a matter of principle, I always think using a dictionary as an API to > properties is a terrible idea. You’re much better off defining an object that > actually has the properties, even if there are a lot of them. That would > solve your difficulty here, since you wouldn’t need two ways of getting to > the properties. Also, you’d avoid the danger inherent in exposing your > mutable backing store (the NSMutableDictionary) to the outside world, always > a prescription for trouble. >
I completely agree, but in this case the dictionary in question is the attributes of NSAttributedString (in a NSTextView), so I don’t have the choice. I have split out numerous individual properties from this so that they are easy to bind to specific UI, such as a menu for Font, a menu for font face, a text field for font size, etc, etc. But ultimately they have to change the attributes dictionary. That all works, it’s just that if other code changes the attributes dictionary (such as the Font Manager) then I need these split out properties to trigger their notifications so that the UI shows the change. The dictionary is being changed in a KVO compliant way, because the entire dictionary is updated and replaced as a whole - the settings within the dictionary are not mutated individually. —Graham _______________________________________________ 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
