Re: Bindings clarification: +setKeys:triggerChangeNotificationsForDependentKey: doesn't affect subclasses?
Re: Bindings clarification: +setKeys:triggerChangeNotificationsForDependentKey: doesn't affect subclasses?
- Subject: Re: Bindings clarification: +setKeys:triggerChangeNotificationsForDependentKey: doesn't affect subclasses?
- From: SA Dev <email@hidden>
- Date: Thu, 28 Jul 2005 16:37:42 -0400
Ah - I do apologize, I see exactly what you're saying. You have *my*
vote for filing an enhancement request. Many other methods
specifically say subclasses must call super.
On Jul 28, 2005, at 4:34 PM, Jim Correia wrote:
On Jul 28, 2005, at 4:27 PM, SA Dev wrote:
Not sure exactly what you're asking, but YOU don't call that
method. +setKeys:triggerChangeNotificationsForDependentKey: is
called automatically in the +initialize method of your class. From
that point on, any changes to the first keys will force any
observers to note a change in the dependent keys. No additional
work is required.
If I misunderstand what you're asking, I apologize.
You misunderstand somewhat - the back channel can be filled in by
my longer question yesterday about the appropriate place to do this
work.
If you do it in initialize, and you don't do the one-time class
test, and you pass self instead of the name of your class it works
because it gets called once for every subclass if and only if the
subclass doesn't also implement initialize. If the subclass
implements initialize and DOES NOT call [super initialize] because
the runtime docs say not to, then it doesn't generate the dependent
notifications for subclasses.
To make this concrete, modify my example so Person has an
initialize method which looks like
+ (void)initialize
{
[self setKeys: [NSArray arrayWithObject: @"name"]
triggerChangeNotificationsForDependentKey: @"uppercaseName"];
}
and Employee has an empty +initialize method.
There are various things I can do to work around this, but I wanted
to know if it was intended to be that way (in which case it should
be documented) or not (in which case I'll file a bug.)
The current implementation either way feels unfortunate because it
requires the Employee class to know that the Person class has a
dependent key that must be registered, depending upon which method
you use to make sure the dependent keys get registered.
Jim
_______________________________________________
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