Re: semantics of init
Re: semantics of init
- Subject: Re: semantics of init
- From: Andrew Pinski <email@hidden>
- Date: Tue, 3 Jun 2003 20:11:23 -0400 (EDT)
>
Okay, that seems fine. However, I'm wondering when you extend some class,
>
are you supposed to respect that rule in your own init functions?
>
>
For example, suppose I extend SomeClass with SomeOtherClass, should I
>
do something like this in the constructor?
>
>
- (void) init
>
{
>
id me = [super init];
>
me->myfields = some_data;
>
return me;
>
}
>
>
as opposed to
>
>
- (void) init
>
{
>
[super init];
>
myfields = some_data;
>
return self;
>
}
Even better (like the first one but also like the second one)
- (void) init
{
if ((self = [super init]) != NULL)
{
myfields = some_data;
}
return self;
}
since init can return NULL you do not want your class to seg fault because of your class.
Thanks,
Andrew Pinski
>
>
This seems stupid and annoying. I'm assuming that nobody in their
>
right mind would do anything but return 'self' from init, or if they
>
did so it would be well-documented and for some no doubt very worthy
>
cause, so I shouldn't worry about it. I'm wondering, though, if there is
>
some nice way to both be safe and not have to write annoying code like my
>
first example.
PS I can think of a case where you do not return self, class clusters and they do not have to be documented to be a class cluster.
Another case is when you can simplify things, for an example an 2+2 can be simplified into 4 in a computer algebra system or x*x*x into x^3 (I have done this before so I know it works).
_______________________________________________
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.