> On 22 May 2015, at 15:03, Jonathan Taylor <jonathan.tay...@glasgow.ac.uk> > wrote: > > 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.
Yeah, same thing I think. Was just talking it through more for my own benefit really :-) > > >> 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… That’s a good point about how atomic accessors make the story a lot more complicated. BUT, why would atomic accessors help your crash? Views are pretty fundamentally tied to the main thread for the most part. Atomic accessors won’t help there. _______________________________________________ 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
