Re: semantics of init -> Question
Re: semantics of init -> Question
- Subject: Re: semantics of init -> Question
- From: Prachi Gauriar <email@hidden>
- Date: Thu, 05 Jun 2003 10:03:59 -0500
- Resent-date: Thu, 05 Jun 2003 10:05:06 -0500
- Resent-from: Prachi Gauriar <email@hidden>
- Resent-message-id: <email@hidden>
- Resent-to: email@hidden
On Thursday, June 5, 2003, at 08:27 AM, Oscar Morales Vivs wrote:
Another situation would be when the setting of a variable is
connected with
some other action, as for example a notification being sent. Of
course, one
can in that case write a public and a private setter with the private
setter
setting the variable and the public setter calling the private setter
and
posting the notification (This is more a design problem)
Suppose I have class A, and class B derived from it. If I create a new
object of class B, and during the execution of class A 'init' I call a
method that is overriden in class B, will it call class A version or
class B version?
It will call the Class B version if you're using self. self refers to
the receiving object.
It that's the case, then I wouldn't suggest using accessors in init as
you can't know what derived classes could do with them. Could cause
problems if the derived class accessor needs some data that hasn't
been initialized. It's a bigger problem in C++, but it can also be a
problem in Objective-C.
I wondered the same thing a few weeks ago and asked the Omnigroup list,
but I only got one reply, but it was a good one. publiclook said:
There is generally no problem using self within an initializer for
several reasons:
A) Objective-C initializes all instance variables to the bit pattern of
all zeros as part of +alloc before any initializer is called.
B) Messages to nil objects are harmless as long as the return value is
not used or is the size of a pointer and can reasonably be 0. This is
unlike Java and C++ in which using a NULL pointer or having unexpected
zeroed data structures probably results in a crash.
C) Accessor methods like -setName: in your example can reasonably be
expected to set instance variables and not have problems with instance
variables that already have a zero value. If they have side effects
such as posting notifications or changing other instance variables,
they can still do that harmlessly during initialization.
D) All messages are dispatched polymorphically in Objective-C so there
are none of the problems with erroneous/misleading virtual member
function calls inside a C++ constructor. Java is similar to Objective-C
in this regard. It is the inability of C++ to cope with this that
makes Java programmers (who came from C++) wary IMHO.
It is possible in certain rare situations for a message sent to self
from within an initializer to result in a non-obvious bug, but on the
other hand, it is easy to write methods that do not document or check
all kinds of implicit pre-conditions. If a method requires
pre-conditions like a certain state of an instance variable, it should
check the validity of the pre-condition and it should be documented.
This has implications far beyond calls from within an initializer.
-Prachi
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.