On 23 May 2015, at 00:21, Graham Cox <graham....@bigpond.com> wrote: > My advice is: forget it. What you’re doing is fine, and it’s the normal way > to make views repaint when a property changes. It’s not code ‘bloat’ either - > @synthesize produces code just as if you’d written it yourself. Any other way > than simply adding a call to -setNeedsDisplay: is MORE code than that.
Just to be clear, I meant source code bloat - in the process of refactoring the code I have been rather horrified at how much of my codebase is really just "glue" code for user interface stuff, in what should be just a GUI wrapper on some scientific code. > What would be quite nice (though maybe too much of a special case and very > unlikely to happen) is a qualifier for properties that would add the > -setNeedsDisplay: automatically as part of the @synthesize, but I doubt that > will ever happen because it a) only pertains to views b) might not be optimal > for some situations, where only part of the view needs updating, and c) made > somewhat redundant by layers, which have a flag that causes a redisplay on a > property change. Ah, now it sounds like layers could be something I should be reading up on then! Maybe another one of those cases of me asking the wrong question because I don't know what the right one is... All of you wrote: > Since you're talking about properties on an NSView subclass, and NSView is > documented as being not thread-safe, the atomicity thing sounds like a big > red herring (or red flag, depending on your preference for fish or cloth). [rambling off the original topic...] You are quite right of course. If I am concerned about atomicity on this particular object then I am definitely doing something wrong. There was probably some end-of-week thinking behind what I did, but the rough train of thought went: - There is necessarily a fair bit of multithreading in my codebase, and I have not found a completely foolproof way of guaranteeing it remains isolated from GUI code (though I know I must do that). I want to use [non-gui-related] properties on other threads, but then sooner or later I end up accidentally causing an interaction with GUI-bound properties and causing an obscure and hard-to-debug crash - A recent such crash involved a double-free of an NSNumber (where to begin looking...!?), and brainstorming this lead me to imagine that accessing a nonatomic property returning an objc object could lead to that happening. - As a result I decided I had no good reason to have any nonatomic properties, and that I would try and remove any use of nonatomic rather than try and decide on a case-by-case basis - This led to warnings about custom setters paired with auto-synthesized getters, which got me looking at this setNeedsDisplay code and wondering if there was a better way of doing that anyway. Probably an overreaction (and very probably not the actual cause of the crash), but I was pretty sure that technically speaking my universal use of nonatomic [for reasons lost in the mists of time] was not correct. If only there was a way of annotating properties as only-to-be-used-from-the-main-thread. I've asked something to that effect previously, though, and nobody had any suggestions. I feel there must be a way of designing-in the safety that I need, but I haven't worked out what it might be. _______________________________________________ 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
