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: Pontus Ilbring <email@hidden>
- Date: Fri, 29 Jul 2005 14:47:52 +0200
On 7/29/05, Jim Correia <email@hidden> wrote:
> Given that, the documentation example which shows registration of
> dependent keys in the initialize method and my example from earlier
> today [1] the challenge is to implement an initialize on Person that
> registers the dependent key, and an implementation of [Employee
> initialize] which does not (because it does not, nor should it know,
> the inner workings of Person) register the dependent keys itself, or
> call [super initialize] in violation of the docs above.
>
> How and when should dependent keys be registered in this case when
> there are subclasses. Either initialize is the wrong place, or you
> have to violate the rules laid out above.
>
> [1] http://lists.apple.com/archives/cocoa-dev/2005/Jul/msg02292.html
Can't you just create a class method
+ (void)registerDependentKeys
which you call from initialize. Now the subclass just needs to know to
call this method, and doesn't need any further insight into its
parent. Seems sufficiently decoupled to me.
_______________________________________________
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