2

I have seen if(self = [super init]), but I recently came across some code that tests for equality rather than makes an assignment, e.g. if(self == [super init]). What is the purpose of this code, and how does it contrast with if(self = [super init])?

For context, this is the entire function:

- (id)initWithDelegate:(id<BSForwardGeocoderDelegate>)aDelegate
{
    if (self == [super init])
    {
        delegate = aDelegate;
    }
    return self;
}
user1
  • 770
  • 1
  • 11
  • 25
  • http://stackoverflow.com/questions/2956943/why-should-i-call-self-super-init – Midhun MP Apr 30 '13 at 12:53
  • http://stackoverflow.com/questions/7840535/should-init-be-assigning-or-testing-equality-on-self-init – Mark McCorkle Apr 30 '13 at 13:05
  • 4
    Why the down votes? Perfectly valid question! – bbum Apr 30 '13 at 13:25
  • The questions linked to by Midhun and MarkM seem to disagree. The second answer in Midhun's linked question says that testing for equality is a better than testing assignment, but MarkM's answer says that testing for equality is likely an unintentional syntax mistake. – user1 Apr 30 '13 at 13:40
  • 2
    @user1 It is because the second answer on Midhun's link -- the part that talks about `==` is flat out wrong. – bbum Apr 30 '13 at 15:08

1 Answers1

4

Checking for equality makes no sense and is just wrong.

Assigning is because super may return a different object.

Wain
  • 118,658
  • 15
  • 128
  • 151
  • Agreed. The `==` version is simply wrong. It will work most of the time, but not always. The `if (self = [super init])` version is slightly ugly (I don't like to see assignments inside if statements), but will produce correct results. – Hot Licks Apr 30 '13 at 15:24