Re: Bindings: Where/when should dependent keys be registered? (when class with dependent keys is subclassed)
Re: Bindings: Where/when should dependent keys be registered? (when class with dependent keys is subclassed)
- Subject: Re: Bindings: Where/when should dependent keys be registered? (when class with dependent keys is subclassed)
- From: Jim Correia <email@hidden>
- Date: Thu, 28 Jul 2005 21:44:13 -0400
On Jul 28, 2005, at 6:39 PM, Fritz Anderson wrote:
On 27 Jul 2005, at 7:37 PM, Jim Correia wrote:
The runtime system sends an initialize message to every class
object
before the class receives any other messages and after its
superclass
has received the initialize message. [...]
...
But more importantly:
Note: Remember that the runtime system sends initialize to
each class
individually. Therefore, in a class’s implementation of the
initialize
method, you must not send the initialize message to its
superclass.
As I read it (and my experience does not contradict this), when you
first use an Employee method, +initialize is sent to Employee, and
serially to each member of its superclass chain, serially from the
top superclass down. Members of the chain that don't implement
+initialize pass their instance of the call up the inheritance
chain, which can result in a superclass of such a class getting
+initialize additional times.
Agreed.
So on first use of Employee, +initialize is sent to Person, and
then to Employee (which if it doesn't implement +initialize,
amounts to triggering Person's initialize on the instance [Employee
class]).
Also agreed. But if you implement +[Employee initialize] in
accordance with the runtime and do no call [super initialize], the
equivalent fo [Employee
setKeys:triggerChangeNotificationsForDependentKey:] is never called,
and dependent notifications don't fire for subclasses.
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