Re: self willChangeValueForKey: @"all keys"???
Re: self willChangeValueForKey: @"all keys"???
- Subject: Re: self willChangeValueForKey: @"all keys"???
- From: mmalcolm crawford <email@hidden>
- Date: Sun, 27 Mar 2005 00:15:00 -0800
On Mar 25, 2005, at 5:02 PM, glenn andreas wrote:
On Mar 25, 2005, at 5:53 PM, mmalcolm crawford wrote:
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).
Oh, sorry, I wasn't trying to sell you on KVO per se, I was trying to
help you feel better about the code you were writing! :-) [It's
actually more relevant to another thread -- more on that anon.]
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).
Presumably the phases of the moons of Jupiter are added as accessor
methods in a category?
In this case it should be possible(*) to use +load for each category:
@implementation FrameworkClass (JupitersMoons)
+(void)load
{
[[self class] setKeys:[NSArray arrayWithObjects:@"date",
@"otherMaster", nil]
triggerChangeNotificationsForDependentKey:@"ganymede"];
// or perhaps
[[self class] setKeys:[self masterKeys]
triggerChangeNotificationsForDependentKey:@"callisto"];
// etc...
}
- (Phases *)ganymede
{
// ...
@end
mmalc
(*) Empirical evidence is thus far supportive... Please let me know
if it ever fails.
It doesn't in this case seem strictly necessary to call [self class]
throughout, but there are cases when the categories get loaded first,
and this might guard against any other dependencies.
_______________________________________________
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