Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
- Subject: Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
- From: Ben Kennedy <email@hidden>
- Date: Fri, 22 May 2015 14:30:17 -0700
On 22 May 2015, at 6:03 am, Jonathan Taylor <email@hidden> wrote:
> 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.
How about cooking up a macro for defining the accessors?
#define DECLARE_PROPERTY(PROPERTY,TYPE) \
@property (nonatomic, copy) TYPE PROPERTY;
#define DEFINE_PROPERTY(PROPERTY,TYPE) \
- (TYPE)PROPERTY \
{ \
return _##PROPERTY; \
} \
\
- (void)set##PROPERTY:(TYPE)x \
{ \
_##PROPERTY = x; \
[self setNeedsDisplay]; \
} \
...
@interface Foo
DECLARE_PROPERTY(widgetName, NSString *);
@end
...
@implmenetation Foo
DEFINE_PROPERTY(widgetName, NSString *);
@end
> 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...
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).
b
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden