Re: semantics of init
Re: semantics of init
- Subject: Re: semantics of init
- From: Marcel Weiher <email@hidden>
- Date: Wed, 4 Jun 2003 17:16:33 +0200
On Wednesday, June 4, 2003, at 02:39 Uhr, j o a r wrote:
On Wednesday, Jun 4, 2003, at 10:09 Europe/Stockholm, Marcel Weiher
wrote:
So I use my accessors to avoid direct instance variable access. This
protects me from self being nil without the test, and it even
protects me from a different type of object being returned. (If the
object being returned isn't compatible in the message-interface, then
it is just broken).
The problem that I see with using accessor methods in init is that it
could possibly create maintenance problems.
I see it the other way around: *not* using the accessors can create
maintenance problems. After all, this is what accessors are here for!
Sending messages to "self" before "self" is fully initialized
This is a C++ idiom that does not exist in Objective-C. -init is just
a message, so you are already sending messages to an object 'before it
is fully initialized', whatever that means (it has no meaning in
Objective-C itself).
could possibly create situations where you, if you're not carefyl, try
to access parts of "self" that is not yet initialized.
If you are not careful, you can always mess up. Such is programming.
However, part of the idea of using accessors in -init is to avoid
'special' mechanisms that tend to be the cause of mess-ups.
Do you see this as a problem, and if so, how do you deal with that?
Yes and no. Yes, this could be a problem, but the problem is not using
accessors in -init, the problem (that needs to be addressed!) is code
that doesn't allow for this. Just as an example: any objects created
in IB will not be created with the standard -init methods, but rather
unarchived and then sent an awakeFromNib. Furthermore, if you create
object from within AppleScript, the will be sent a plain -init and any
additional initialization parameters via set-accessors.
So you should write your objects in such a way that they can handle
this and do not depend on "magic" in the initialization methods. I
think you will find that your code becomes more straight-forward,
simpler and more robust.
The whole
initialization-is-special-until-the-object-is-fully-initialized idea
that is behind C++ constructors sounds compelling at first glance, but
IMNSHO has failed rather dramatically.
[example of set-accessor changing]
...or do you have some other pattern to protect you from this
potential pitfall?
Well, I can imagine (and actually have) code where the set-accessor
changes and you *want* the superclass init to pick this change up.
After all, that was one of the points of having set-accessors, right?
Yes, there may be cases where you do not want this to happen, where you
want to use direct access to avoid changes in accessor-behavior. But
those cases should be the (rare) exception from the rule.
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
_______________________________________________
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.