• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Best Way to Handle Properties?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Best Way to Handle Properties?


  • Subject: Re: Best Way to Handle Properties?
  • From: Graham Cox <email@hidden>
  • Date: Thu, 21 Aug 2008 14:46:02 +1000


On 21 Aug 2008, at 2:31 pm, Shawn Erickson wrote:

On Wed, Aug 20, 2008 at 10:42 AM, Dave <email@hidden> wrote:

Yes, all 56 properties are required for the object to be valid, so in the
initializer I set the NSString pointers to nil, zeroize the integers and set
the dataValid flag to FALSE.

Objective-C guarantees that all ivars will be initialized to zero (aka nil, false, NO, etc.) when you allocate an object. You don't need to set ivars to zero yourself in the initializer.



This brings up something that I had to deal with recently.

I wrote some code that a third party wanted to use. This third party had a requirement that I conform where possible to their coding standards. This was generally not a big problem, but one of them was, in my opinion, ridiculous.

"In an Objective-C init method, all instance variables that are expected to be initialized to zero should be asserted to verify this".

In other words, I'm expected to write my init methods like this:

- (id) init
{
    self = [super init];
    if( self != nil )
    {
        NSAssert( myIvar1 != nil, @"expected init to zero!");
        NSAssert( myIvar2 != nil, @"expected init to zero!");
        NSAssert( myIvar3 != nil, @"expected init to zero!");
        NSAssert( myIvar4 != nil, @"expected init to zero!");
    }

    return self;
}


Harmless enough but stupid, IMO. I argued about it and they said, well, asserts aren't *supposed* to fire anyway, so this just catches something you didn't expect. OK, but since this is guaranteed by the runtime you are effectively saying you don't trust the runtime, and if you don't trust the runtime, how can you write *any* code at all?


I added the code to keep them happy, but then another worse problem cropped up - it actually makes many of the init methods harder to read, because of all the clutter. That in turn led to a couple of real bugs. And I've never yet seen one of these asserts ever fire. I'm gradually taking them all out again...

Anyone got any thoughts on this? Is there any valid case for doing this, and having this written into a coding standard?


cheers, Graham _______________________________________________

Cocoa-dev mailing list (email@hidden)

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:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Best Way to Handle Properties?
      • From: "Shawn Erickson" <email@hidden>
References: 
 >Best Way to Handle Properties? (From: Dave <email@hidden>)
 >Re: Best Way to Handle Properties? (From: Ken Thomases <email@hidden>)
 >Re: Best Way to Handle Properties? (From: Dave <email@hidden>)
 >Re: Best Way to Handle Properties? (From: Ken Thomases <email@hidden>)
 >Re: Best Way to Handle Properties? (From: Dave <email@hidden>)
 >Re: Best Way to Handle Properties? (From: Ken Thomases <email@hidden>)
 >Re: Best Way to Handle Properties? (From: Dave <email@hidden>)
 >Re: Best Way to Handle Properties? (From: "Shawn Erickson" <email@hidden>)

  • Prev by Date: Re: Core Data - "Items cannot be deleted from X"
  • Next by Date: Re: Best Way to Handle Properties?
  • Previous by thread: Re: Best Way to Handle Properties?
  • Next by thread: Re: Best Way to Handle Properties?
  • Index(es):
    • Date
    • Thread