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 there is some magic one can pull off to > get to the original setters.
In fact, I was just about to post on this. As an alternative to the observer approach, it certainly is possible to switch a method of your own choosing in to replace the synthesized setter. Getting the coding-time usability right seems like the main issue. 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 super in the subclass. There's still a bit of ugliness in this approach (e.g. you have to expose the private superclass in the subclass's public .h file), though not much perhaps. Also, since the compilers have been getting pickier in their recent versions regarding the way property methods are defined, there may turn out to be a compile-time obstacle, but in principle I think this approach should work -- you'd basically be getting the compiler to delve into the runtime for you. 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? Regarding the observer approach… I have no great technical, moral or psychological objections to this approach, but a couple of small things still worry me: -- The source code for a simple custom setter is kind of … obvious … to read. It's an instantly recognizable pattern. I've always found observations somewhat difficult to come back to and understand, after the code has already been written, perhaps because the 'observe…' method exists at some random, disconnected place, and decoding the execution flow through it can be mind-bending in all but the simplest cases. Quite often this approach leads to nested observations, with the add/remove observers needing to get done inside an 'observe…' method also. OTOH, maybe a short course of therapy would cure me of the feeling. -- Adding an observer creates a not-insignificant amount of internal machinery per observed object. For observing a few views, this isn't significant in practice. As a design principle for a generally useful mechanism, the prospect of unwittingly creating observations for maybe hundreds of thousands of objects seems like a drawback. -- There's an actual semantic difference between the two approaches. If you write custom setters in a class hierarchy, you get to control on a class-by-class basis whether the behavior added at one level (such as the 'setNeedsDisplay:') is also inherited. If you add an observer, even an explicit custom setter override at a lower level (for example, one that wants to do 'setNeedsDisplayInRect:' instead) can't turn off the observer behavior. In other words, encapsulation is violated. That's fine if that's what you want, but it isn't really a drop-in replacement for the semantics of custom setters. _______________________________________________ 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
