Re: adding something to a setter

> Isn't this the same as the discussion we had here? > > > > If so, let's pretend I just repeat my answer. :) m. Wow - a black cat! (http://www.imdb.com/title/tt0133093/quotes) Somehow I didn't s

Re: adding something to a setter

On Thu, 06 Oct 2011 13:28:43 +0200, Torsten Curdt said: >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. Isn't this the same as the discussion

Re: adding something to a setter

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 cod

Re: adding something to a setter

Do not use self as your observation context. Your observation context has to be unique for all observers of the object. “self” is a bad choice. Also, you should only do your own work in the case that the observer is your observer. In the code below, you are also doing your work in the case whe

Re: adding something to a setter

On Oct 6, 2011, at 17:12 , Charles Srstka wrote: > But isn't creating a whole abstract superclass for this a lot more of a > hassle than just making a private property? *Some* more. I'm not sure about a *lot* more. > What would you get from that approach that you wouldn’t get from just having

Re: adding something to a setter

On Oct 6, 2011, at 6:22 PM, Quincey Morris wrote: > It occurs to me that there may be a lower-tech solution. If you created an > abstract superclass of the class whose setters you wanted to override, you > could synthesize the properties in the superclass, override them normally, > and call sup

Re: adding something to a setter

The superclass approach is sneaky ...didn't think about that. > Again, though, I remain unconvinced that going to all this trouble is worth > it, just to eliminate a lingering sense of unease. Perhaps a short course of > therapy instead? LOL - maybe :) Well, TBH this is less of "I want to use th

Re: adding something to a setter

On Oct 6, 2011, at 15:34 , Torsten Curdt wrote: > While I agree that this is not a big deal in practice, I am sure you'd > agree that it would be indeed nice if we could somehow call out to the > synthesized setters. I don't have so deep insights into the Obj-C > runtime but I was wondering if the

Re: adding something to a setter

On Oct 6, 2011, at 5:34 PM, Torsten Curdt wrote: > While I agree that this is not a big deal in practice, I am sure you'd > agree that it would be indeed nice if we could somehow call out to the > synthesized setters. I don't have so deep insights into the Obj-C > runtime but I was wondering if th

Re: adding something to a setter

> 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! Just because I can now synthesize setters doesn't make it suck less. Over it or under it ;) The intend of this mail was not t

Re: adding something to a setter

On Oct 6, 2011, at 4:12 PM, Kyle Sluder wrote: > On Thu, Oct 6, 2011 at 12:33 PM, Quincey Morris > wrote: [...] >> 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

Re: adding something to a setter

On Thu, Oct 6, 2011 at 12:33 PM, Quincey Morris wrote: > 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

Re: adding something to a setter

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. N

Re: adding something to a setter

On Oct 6, 2011, at 10:57 AM, Mike Abdullah wrote: > Note that you should really pass in a context pointer and test that in the > -observe… method, rather than testing the key paths. Call super for all other > key paths. Ah, right. I've updated my gist accordingly. --Andy _

Re: adding something to a setter

On Oct 6, 2011, at 10:55 AM, Andy Lee wrote: > It observes a fake view property called myNeedsDisplay. > > Here is a totally untested MyDisplayTickler class, plus a category on NSView: > > Oops, in my code I called the fake property "needsTickle", not "myNeedsD

Re: adding something to a setter

On 6 Oct 2011, at 15:23, Stephan Michels wrote: > > Am 06.10.2011 um 15:54 schrieb Torsten Curdt: > >> Well, if the model is more complex and you bind the view to the model >> you can of course trigger the re-display on the observed changes. But >> what about a simple title property of e.g. a N

Re: adding something to a setter

On Oct 6, 2011, at 9:16 AM, Torsten Curdt wrote: > Hm... using KVO for an object to observe it's own properties? > That's feels wrong to me. > Is that just me? You could factor the observing out into a separate object. I'm just rattling this idea off the top of my head, so it might be flawed (if

Re: adding something to a setter

Am 06.10.2011 um 15:54 schrieb Torsten Curdt: > Well, if the model is more complex and you bind the view to the model > you can of course trigger the re-display on the observed changes. But > what about a simple title property of e.g. a NSButton? > > ...and I guess triggering a re-display is not

Re: adding something to a setter

Well, if the model is more complex and you bind the view to the model you can of course trigger the re-display on the observed changes. But what about a simple title property of e.g. a NSButton? ...and I guess triggering a re-display is not the only use case for this "setter extension" - or whatev

Re: adding something to a setter

But probably that bad feeling is self-inflicted ... At least for standard views or controls, if there is a need to redisplay, the property in question should probably belong to a model object not a view object. And in that case your object would not observe its *own* property but a property of

Re: adding something to a setter

On Oct 6, 2011, at 6:28 AM, Torsten Curdt 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. > >

Re: adding something to a setter

On 6 Oct 2011, at 14:16, Torsten Curdt wrote: > Hm... using KVO for an object to observe it's own properties? > That's feels wrong to me. > Is that just me? No, definitely not just you... But then, I find KVO pretty wrong in the first place. if (*ra4 != 0xffc78948) { return false; } _

Re: adding something to a setter

Hm... using KVO for an object to observe it's own properties? That's feels wrong to me. Is that just me? cheers, Torsten ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact

Re: adding something to a setter

On 6 Oct 2011, at 13:36, Mike Abdullah wrote: > > On 6 Oct 2011, at 13:09, Thomas Davie wrote: > >> >> Does anyone have any comments on why that might not work, before I file a >> bug report to request it? > > Well it would become rather unreadable for anything more than a single line > of

Re: adding something to a setter

I use KVO to execute custom code if a property has changed. [self addObserver:self forKeyPath:@"graphics" options:(NSKeyValueObservingOptionNew|NSKeyValueObservingOptionOld) context:self]; - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change cont

Re: adding something to a setter

On 6 Oct 2011, at 13:09, Thomas Davie wrote: > I don't know of any better way than simply writing the setters yourself. One > thing I'd love to see apple add to the language is allowing us to specify a > code block to be included in setter and getting in the synthesize: > > @property (readwri

Re: adding something to a setter

I don't know of any better way than simply writing the setters yourself. One thing I'd love to see apple add to the language is allowing us to specify a code block to be included in setter and getting in the synthesize: @property (readwrite, retain, nonatomic) NSString *theValue; @synthesize (

adding something to a setter

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 setNeedsDispl