It's perhaps helpful to remember that property was introduce to remove the
annoyance with having to define boilerplate accessor for 90% of your
properties. People are now writing 90% less accessor code, so writing one
more for your case below seems tolerable. After all, it's just a few lines
of code.
Yi
On Thu, Oct 6, 2011 at 4:28 AM, Torsten Curdt <tcu...@vafer.org> wrote:
> The property syntax is great until you need one more thing.
>
> Think of a NSView and that view displays a value.
>
> @synthesize value;
>
> 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.
> Is there a way to forward the setting to the originally synthesized
> setter? Super cannot be it.
>
> Of course one could add another selector that to the interface
>
> - (void) setValueAndUpdateDisplay:(NSString*)theValue
> {
> self.value = theValue;
> [self setNeedsDisplay:YES];
> }
>
> ...but that sucks, too.
>
> There gotta be a better way!
> How do you deal with this?
>
> cheers,
> Torsten
> _______________________________________________
>
> 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/yioncocoa%40gmail.com
>
> This email sent to yionco...@gmail.com
>
_______________________________________________
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
