Best practice question

  • Hi all,

    I've seen many variations of the init method and I'm wondering which
    is the best way to go. Currently I do it like this;

    - (id)init
    {
      if (self = [super init])
      {
        // Perform init code
        return self;
      }
      return nil;
    }

    Many thanks, Alan

    --
    // Quotes from yours truly -------------------------
    "You don't forget, you just don't remember."
    "Maturity resides in the mind."
    "Silence is the Universe's greatest gift."
    "When the World realizes that religion really is unimportant, then it
    shall evolve."
  • On Oct 27, 2006, at 3:46 PM, Alan Smith wrote:

    > Hi all,
    >
    > I've seen many variations of the init method and I'm wondering which
    > is the best way to go. Currently I do it like this;
    >
    > - (id)init
    > {
    > if (self = [super init])
    > {
    > // Perform init code
    > return self;
    > }
    > return nil;
    > }
    >
    > Many thanks, Alan

    I don't care for multiple return statements, and in your code, the
    second one is redundant anyway, so I'd do it like this:

    - (id)init
    {
    self = [super init]; // Putting this here avoids a warning about
    unintentional assignment in the if below
    if (self)
    {
      // Do stuff
    }
    return self; // Only need one return b/c we're testing for nil in
    the if above
    }

    (typed in Mail, blah blah)

    HTH,
    Glen
  • On 10/27/06, Alan Smith <alanrogersmith...> wrote:
    > Hi all,
    >
    > I've seen many variations of the init method and I'm wondering which
    > is the best way to go. Currently I do it like this;
    >
    > - (id)init
    > {
    > if (self = [super init])
    > {
    > // Perform init code
    > return self;
    > }
    > return nil;
    > }

    IMHO it is cleaner and functionally equivalent to have a single exit point...

    - (id) init
    {
        if (self = [super init]) {
            ....
            ...on init failure release ourself and set self to nil...
        }

        return self;
    }

    I also personally pull the self = [super init] out of the if statement
    and have the if statement check against != nil. For example...

    - (id) init
    {
        self = [super init];
        if (self != nil) {
            ...
        }

        return self;
    }

    -Shawn
  • On 27 okt 2006, at 22.54, Shawn Erickson wrote:

    > I also personally pull the self = [super init] out of the if statement
    > and have the if statement check against != nil. For example...
    >
    > - (id) init
    > {
    > self = [super init];
    > if (self != nil) {
    > ...
    > }
    >
    > return self;
    > }

    When we're on the topic of "best practices", it could be worth noting
    that placing the constant value (nil in this case) to the left of the
    compare operator decreases the likelihood of an involuntary assignment.

    Like Shawn, I also like to make the check for a nil value explicit,
    so in my case it looks like this:

    - (id) init
    {
    if (nil != (self = [super init]))
    {
      // Stuff
    }

    return self;
    }

    j o a r
  • We enable extra warnings (using the "-W -Wall" flags) which generates
    a warning for assignments in if statements, and do it like this:

    - (id)init
    {
      if ((self = [super init])) {
        ...
      }
      return self;
    }

    - Chris

    > When we're on the topic of "best practices", it could be worth
    > noting that placing the constant value (nil in this case) to the
    > left of the compare operator decreases the likelihood of an
    > involuntary assignment.
    >
    > Like Shawn, I also like to make the check for a nil value explicit,
    > so in my case it looks like this:
    >
    > - (id) init
    > {
    > if (nil != (self = [super init]))
    > {
    > // Stuff
    > }
    >
    > return self;
    > }
    >
    > j o a r
    >
    >
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/<chris...>-
    > systems.com
    >
    > This email sent to <chris...>
  • I always felt it a bit awkward to

    On 28-okt-2006, at 0:31, Chris Suter wrote:

    > We enable extra warnings (using the "-W -Wall" flags) which
    > generates a warning for assignments in if statements, and do it
    > like this:
    >
    > - (id)init
    > {
    > if ((self = [super init])) {
    > ...
    > }
    > return self;
    > }
    >
    > - Chris
    >
    >> When we're on the topic of "best practices", it could be worth
    >> noting that placing the constant value (nil in this case) to the
    >> left of the compare operator decreases the likelihood of an
    >> involuntary assignment.
    >>
    >> Like Shawn, I also like to make the check for a nil value
    >> explicit, so in my case it looks like this:
    >>
    >> - (id) init
    >> {
    >> if (nil != (self = [super init]))
    >> {
    >> // Stuff
    >> }
    >>
    >> return self;
    >> }
    >>
    >> j o a r
    >>
    >>
    >> _______________________________________________
    >> Do not post admin requests to the list. They will be ignored.
    >> Cocoa-dev mailing list      (<Cocoa-dev...>)
    >> Help/Unsubscribe/Update your Subscription:
    >> http://lists.apple.com/mailman/options/cocoa-dev/<chris...>-
    >> systems.com
    >>
    >> This email sent to <chris...>
    >
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/mailings%
    > 40obviousmatter.com
    >
    > This email sent to <mailings...>
  • I always felt a bit awkward to reassign self so I use the following:

    - (id)init
    {
    if (self != [super init])
      return nil;

    // do stuff

            return self;
    }

    On 28-okt-2006, at 0:31, Chris Suter wrote:

    > We enable extra warnings (using the "-W -Wall" flags) which
    > generates a warning for assignments in if statements, and do it
    > like this:
    >
    > - (id)init
    > {
    > if ((self = [super init])) {
    > ...
    > }
    > return self;
    > }
    >
    > - Chris
    >
    >> When we're on the topic of "best practices", it could be worth
    >> noting that placing the constant value (nil in this case) to the
    >> left of the compare operator decreases the likelihood of an
    >> involuntary assignment.
    >>
    >> Like Shawn, I also like to make the check for a nil value
    >> explicit, so in my case it looks like this:
    >>
    >> - (id) init
    >> {
    >> if (nil != (self = [super init]))
    >> {
    >> // Stuff
    >> }
    >>
    >> return self;
    >> }
    >>
    >> j o a r
    >>
    >>
    >> _______________________________________________
    >> Do not post admin requests to the list. They will be ignored.
    >> Cocoa-dev mailing list      (<Cocoa-dev...>)
    >> Help/Unsubscribe/Update your Subscription:
    >> http://lists.apple.com/mailman/options/cocoa-dev/<chris...>-
    >> systems.com
    >>
    >> This email sent to <chris...>
    >
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/mailings%
    > 40obviousmatter.com
    >
    > This email sent to <mailings...>
  • I think that's broken if the super class happens to change self to
    another object, which whilst rare, is possible I believe.

    - Chris

    On 28/10/2006, at 4:59 PM, Diederik Hoogenboom wrote:

    > I always felt a bit awkward to reassign self so I use the following:
    >
    > - (id)init
    > {
    > if (self != [super init])
    > return nil;
    >
    > // do stuff
    >
    > return self;
    > }
  • http://wilshipley.com/blog/2005/07/self-stupid-init.html

    On Oct 28, 2006, at 09:34, Chris Suter wrote:

    > I think that's broken if the super class happens to change self to
    > another object, which whilst rare, is possible I believe.
    >
    > - Chris
    >
    > On 28/10/2006, at 4:59 PM, Diederik Hoogenboom wrote:
    >
    >> I always felt a bit awkward to reassign self so I use the following:
    >>
    >> - (id)init
    >> {
    >> if (self != [super init])
    >> return nil;
    >>
    >> // do stuff
    >>
    >> return self;
    >> }
  • The many postings on this subject got me looking at some code I wrote
    a while back, and now I'm wondering whether it is potentially wrong.

    Here's the code and a question (as a comment):

    - (id)init:(int)vectorLength {
    if (nil != (self = [super init])) {
      int *theArray = (int*)malloc((size_t)(vectorLength*sizeof(int)));
      if (theArray != NULL) {
      // do stuff
      }
      else {
      [super dealloc]; // should this be [super release] rather than
    [super dealloc]?
      return nil;
      }
    }

    return self;
    }

    Thanks,
    Boyd
  • I see that when a document project is created, the boiler plate for
    MyDocument.m reads

    @implementation MyDocument

    - (id)init
    {
        self = [super init];
        if (self) {

            // Add your subclass-specific initialization here.
            // If an error occurs here, send a [self release] message
    and return nil.

        }
        return self;
    }

    so, unless someone tells me that Apple's got it wrong, that's what
    I'll go with.

    Boyd

    On Oct 29, 2006, at 12:12 PM, Boyd Collier wrote:

    > The many postings on this subject got me looking at some code I
    > wrote a while back, and now I'm wondering whether it is potentially
    > wrong.
    >
    > Here's the code and a question (as a comment):
    >
    > - (id)init:(int)vectorLength {
    > if (nil != (self = [super init])) {
    > int *theArray = (int*)malloc((size_t)(vectorLength*sizeof(int)));
    > if (theArray != NULL) {
    > // do stuff
    > }
    > else {
    > [super dealloc]; // should this be [super release] rather than
    > [super dealloc]?
    > return nil;
    > }
    > }
    >
    > return self;
    > }
    >
    >
    > Thanks,
    > Boyd
  • On 29 okt 2006, at 21.12, Boyd Collier wrote:

    > [super dealloc]; // should this be [super release] rather than
    > [super dealloc]?

    Most definitively. Never, ever, call dealloc - besides when you call
    the super implementation from an override method. See the comments
    for the dealloc method in the NSObject reference documentation.

    j o a r
previous month october 2006 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today