Thursday, July 1, 2010

Synthesize by Default

Posted by hiday81 at 2:42 PM
So, in my previous post, I told you I was excited about the "synthesize by default" functionality that's now available in LLVM 1.5. And I am, very much so. But it turns out there's a caveat that tempers my excitement at the moment.

With synthesized iVars, we've had direct access to the underlying synthesized variable for a while now, so if you created a class like this:

#import <UIKit/UIKit.h>

@interface MyViewController : UIViewController
{
}

@property (nonatomic, retain) NSString *foo;
@end


You're able to access the NSString variable foo that backs the property of the same name within the scope of your class. So, in your dealloc method, you can do this, to give one common example:

- (void)dealloc
{
[foo release], foo = nil;
[super dealloc];
}

However, if you enable the "synthesize by default" feature in LLVM 1.5 and use it, meaning you don't actually have a @synthesize statement for the foo property, you lose this direct access to the underlying variables, leaving you with a bit of a conundrum - how do you do your memory cleanup without unintentionally triggering unwanted functionality, such as those in a lazy accessor or some more involved mutators.

Earlier today, I tweeted a question asking about the correct way to deal with this situation. After a bit of a Who's on First-like back and forth with many smart people, it finally came out that this is a bug in LLVM, not an intentional design decision. Hopefully it will be fixed before too long, but in the meantime, the best answer is probably to just keep using @synthesize.

Thanks to a whole bunch of people on Twitter, many of whom I'm sure I missed!

0 comments:

Post a Comment

Related Post

 

Copyright © 2011 Next Iphone | Store Mobile Phone Store