Re: self willChangeValueForKey: @"all keys"???
Re: self willChangeValueForKey: @"all keys"???
- Subject: Re: self willChangeValueForKey: @"all keys"???
- From: glenn andreas <email@hidden>
- Date: Fri, 25 Mar 2005 19:02:37 -0600
On Mar 25, 2005, at 5:53 PM, mmalcolm crawford wrote:
On Mar 25, 2005, at 10:26 AM, glenn andreas wrote:
So I've got a class (an ephemeris that calculates all sort of
information about sun/moon/planets/etc...) that has a whole bunch of
derived values (as in dozens, and probably many more than that later)
that change when a single "master" value changes, [...]
As I see it, I can either write a boat load of [self setKeys:
[NSArray arrayWithObject: @"master"]
triggersChangeNotificationsForDependantKey: @"key1"] during my
initialize method, or else do a similar thing in when the master
value is set with "willChangeValueForKey:"/"didChangeValueForKey:".
Either way, I need to be constantly updating this to make it longer
and longer (and when I'm done I could possible have keys in the
hundred+ range).
To make things worse, if there are additional categories added with
more derived information (so I can add on methods for different sort
of astronomical information), so though I separate the object into
nice distinct categories of functionality, I constantly have to
update the base implementation (which is certainly error prone).
Is there any sort of magic "everything has changed" key?
No, there isn't an "everything changed" key.
I can certainly appreciate that it may be considered tedious or error
prone to have to specify the
triggersChangeNotificationsForDependantKey: dependencies, however:
As you're toiling though it, you should bear in mind the amount of
other code you're *not* writing. Consider what you would have to do
to ensure a consistent user interface etc. if you were not using KVO.
You don't need to sell me on KVO - it's pretty much my first answer on
how to do something that involves the UI (for better or worse).
If it helps to justify the intellectual endeavour, consider the
implementation as business logic. It is code that is essential to
write to properly specify the behaviour of your model objects...
The problem is that this class is designed to be extended with
additional categories (it may end up a public framework), and obviously
if somebody wants to add, say, the phases of the moons of Jupiter,
there's no way to get those things added as dependent keys (since you
can't safely add +initialize in a category, and there's no
+initializeCategory method).
Right now I'm trying the "scan all methods in +initialize for things
that might be accessor" (return something, have no parameters, don't
start with an underscore), but this won't work if the additional
categories are loaded dynamically later. OTOH, scanning for accessors
in the master setter may not work as well due to posing (since the
class is now something else, and I can't just look in the instance
variables, though I could probably try NSClassFromString).
Glenn Andreas email@hidden
<http://www.gandreas.com/> oh my!
Mad, Bad, and Dangerous to Know
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden