Thanks for your reply Mike: > Well you could have a single key which you observe internally, and which all > the other keys feed into. Whenever it “changes”, treat that as time to mark > as needing display. That way you’re asking AppKit to do the work of creating > all the other observations for you.
I think this is what I was describing here, isn’t it (or am I misunderstanding you?): >> I could create a single “dummy” property of my own, say that changes to all >> these other properties affect that key, and then monitor that single key >> using KVO (and call setNeedsDisplay whenever it gets “tickled” by some other >> property change). That would do what I want, but feels a little bit hacky. > It all seems rather wasteful though. You’ve added a couple of layers of > indirection into the system to save a handful of lines of code. Is it really > that big a deal to write some custom setters? They’re only four lines long > each. I agree that it’s extra indirection, but since performance is never going to be an issue, I feel it’s a slight gain on tidiness and maintainability. I agree that it’s not a big deal for one property, but when there are lots it starts to add up. And it’s not just the setters - what finally spurred me into action was the decision that I wanted all my properties to be atomic (which may or may not be related to an occasional crash I have been seeing). That means writing a correct threadsafe getter for each one as well... _______________________________________________ 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
