Re: semantics of init
Re: semantics of init
- Subject: Re: semantics of init
- From: j o a r <email@hidden>
- Date: Wed, 4 Jun 2003 14:39:15 +0200
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?
Example:
@implementation MyClass
- (id) init
{
// Init using accessor methods
}
- (void) setSomeValue:(id) newVal
{
// Setting value here
}
@end
So far all is fine. Now, if we at a later time want to add a
notification for changes to some attribute of this object:
- (void) setSomeValue:(id) newVal
{
// Setting value here
// Posting notification here
}
...some other object that listens for this notification could try to
access this object instance before it's fully initialized.
Would you keep multiple accessor methods, something like this:
- (void) setSomeValue:(id) newVal
{
// Setting value here
}
- (void) setSomeValueAndNotify:(id) newVal
{
[self setSomeValue: newVal];
// Posting notification here
}
...or do you have some other pattern to protect you from this potential
pitfall?
j o a r
_______________________________________________
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.