On Oct 6, 2011, at 04:28 , Torsten Curdt wrote:
> Now you also want to setNeedsDisplay: when a new value is set. So one
> can override the setter.
>
> - (void)setValue:(NSString*)theValue
> {
> ...
> [self setNeedsDisplay:YES];
> }
>
> but - you would have to implement the setter yourself. No big deal -
> but... it sucks.
I think it really doesn't suck. You've just been lucky enough so far to be able
to ride around on synthesized setters, so an override feels bad. Get over it
already!
The only part of a setter override that perhaps hurts (other than having to
type a few extra keystrokes) is that you lose access to the lightweight
implementation of the "atomic" attribute. It's easy to obsess about that too,
but the class of thread synchronization problems that atomicity actually
solves, compared to the class of synchronization problems that need a
higher-level strategy, is so small that it's not worth avoiding setters only
for this reason.
By all means use self-observation if that solves your problem. There's
absolutely nothing wrong with it, so any negative feelings you might have are
just another perceptual problem. Note, however, that because the observer
mechanism is so clunky, you're going to write *more* lines of code this way
than in overriding the setter, yet all it buys you is the unwanted/unnecessary
"atomic" implementation.
FWIW.
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
