Re: semantics of init
Re: semantics of init
- Subject: Re: semantics of init
- From: Marco Scheurer <email@hidden>
- Date: Wed, 4 Jun 2003 15:39:38 +0200
On Wednesday, June 4, 2003, at 02:39 PM, 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. Sending messages to "self"
before "self" is fully initialized could possibly create situations
where you, if you're not carefyl, try to access parts of "self" that
is not yet initialized. Do you see this as a problem, and if so, how
do you deal with that?
That's a reason why most of the time, I do not use accessors in init,
but directly set the ivar to the initial value.
Another way of taking care of this, as you said, would be to have two
sets of optional accessors methods. If you name them like this:
- (void) _setThing:(Thing *) aThing;
- (void) setThing:(Thing *) aThing;
then you can one or the other KeyValueCoding methods takeValue:forKey:
and takeStoredValue:forKey: to set your variable. They have different
search strategies to pick up the accessor method that will be used (see
NSKeyValueCoding informal protocol doc). In the general case, you would
use takeValue:forKey:. When initializing or unarchiving, you would use
takeStoredValue:forKey:.
The advantage is that you don't have to care weither _setThing or
setThing or both are implemented.
The big disadvantage, IMHO, that using named keys to refer to variables
is unreliable. You loose too much compile-time checks.
If you do not wish to rely on this KVC feature, you'd be better off
using another name than _setThing. Using underscore as a method prefix
is frowned upon.
Marco Scheurer
Sen:te, Lausanne, Switzerland
http://www.sente.ch
_______________________________________________
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.