Patrick,
I don't really know if I am right, because of lack of experience. Please,
correct me if I'm wrong, but... Why would anyone write code like that?
I mean, if one subclasses NSObject and doesn't override +init, it will return
self -- or, maybe, nil -- anyways.
So, I would assume that [super init] would only be called inside an +init or
+initWithWhatever: method, right? Like this:
+ (id*)init
{
[super init];
// initialize some other instance vars, etc. ...
[return self];
}
So, in case a class' +init method can return nil and you want to subclass it,
the code should be more like:
+ (id*)init
{
if ([super init] != nil)
{
...
[return self];
}
else
{
return nil; // or return something else, throw an exception,
whatever...
}
}
I am just curious, because I think it's strange to write "self = [super init]"
anywhere other than in an overriden +init. Am I right?
Cheers,
Flavio
On 08/05/2010, at 01:23, Patrick M. Rutkowski wrote:
> Will NSObject's init method ever really return nil?
>
> E.g. if I sub-class NSObject, then is it worth checking for nil after
> doing self = [super init]?
>
> I know there are many classes in UIKit and Cocoa which most definitely
> can return nil from their -init's, as an indication of failure. But
> will this ever be the case with NSObject?
>
> -Patrick
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
