Does omitting the declaration of ivars for properties might cause trouble or leaks?

I started to learn and develop for iOS4, so I just skipped the old ivar declaration convention and started to use pure properties without even declaring ivars. Everything went fine, I even released my first homemade app on the app store. But then at my dev company, guys told me that they are still using old convention and are declaring ivars with underscored names, use properties and synthesize them (see example at the end). They also said that they are using properties only when outside access to ivars is needed, and for inner access they use direct ivars (for custom classes). I was told that they are doing so because they were experiencing some weird leaks, that sometimes appeared when using custom classes and nil'ying their properties in viewDidUnload (because setting nil to properties sometimes didn't release those ivar objects)

Just wondering why should I bother to use ivar declaration when using properties and synthesize does all the needed stuff. I can even access ivars directly using their names without self in dealloc. So, does anybody got problems with that or many of you still are sticking with the old declaration convention?

@interface ContactModel : NSObject {

  NSString *_firstName;
}

@property (nonatomic, retain) NSString *firstName;

@end

@implementation ContactModel

@synthesize firstName = _firstName;

-(void)dealloc{
  [_firstName release];开发者_JAVA百科
  [super dealloc];
}
@end

Should also note, that Apple still uses that old declaration style when generating main app delegate class file and synthesize window=_window. Hm, currently, I'm a little bit confused about what convention should I take, so any ideas are welcome :)

---

In the modern runtime you don't need the ivar declaration, but synthesize a=_a is still useful to make a distinction between self.a (accessors) and _a (direct access). If @property/@synthesize was leaking I think we should know it by now.

AFAIK using ivars instead properties is only useful if you want @protected access (access to subclasses only), or support the old runtime.

In dealloc you should release the property directly whether you are using ivar declaration and @properties, and optionally you can nil or not.

---

i favor the 'old way' because i favor consistency and (more importantly) encapsulation.

Consistency

personally, i just want a good idea of the object's size and complexity by looking one place.

example: when you implement dealloc, do you prefer to refer to multiple places? not me. it's more complicated than is necessary. i don't want to figure out what i need to cleanup by creating a set from all ivars and properties. properties alone are not enough because they also end up in multiple places (interface, private categories) =\

so the lesser evil imo is to declare ivars so everything is in one place and you have a quick reference to the object's complexity (as well as a good input for some code generators).

Encapsulation

when you see a program where most objects' ivars/properties are visible and read/writable... that's not OOD, it's a mess. when you need to describe it politely, it's the anti-pattern 'Object Orgy'. unfortunately, it's relatively common in objc programs (partly due to language/runtime restrictions).

ivars with prefixed underscores: personally, i don't use that convention in objc. if that's how their code is written, then go with it (not a big deal).

They also said that they are using properties only when outside access to ivars is needed, and for inner access they use direct ivars (for custom classes).

right - here's where attempts at encapsualtion enter the picture. go with it and embrace proper encapsulation.

I was told that they are doing so because they were experiencing some weird leaks, that sometimes appeared when using custom classes and nil'ying their properties in viewDidUnload (because setting nil to properties sometimes didn't release those ivar objects)

ideally, they would have provided you with a better explanation (and gotten to the root of the specific problem at the time).

it's likely that their mystery program(s) did not make a clear enough distinction from its members (data), interface, and its execution. when those overlap, it's not uncommon to lose track of ownership. that case is a general sign of disorganization and/or an implementation extending beyond expectations. if you organize/write classes properly, ivar/property tracking is dead simple (presumably, they are making progress by favoring encapsualtion). as well, protected is the default visibility; i recommemnd private as your default.

Just wondering why should I bother to use ivar declaration when using properties and synthesize does all the needed stuff. I can even access ivars directly using their names without self in dealloc. So, does anybody got problems with that or many of you still are sticking with the old declaration convetion?

• a program that is well designed is not composed of data blobs (with publicly or property accessible variables).
• in most cases, state (e.g. ivars) should not directly map to interface.
• keep your data and impementations well hidden from others.
• even 'private' properties can be an easy source of error (their selectors may be performed or overridden).
• when private is your default and the ivar is truly inaccessible externally, you can reduce a lot of complexity.

so... i see it as they are making this request to make your life simpler by reducing external exposure to state and ultimately to the program's complexity. they have admitted to having had problems in the past, and they are trying to use encapsulation to reduce complexity and chances for errors. good for them.

i know, some programmers just prefer everything publicly visible and mutable - writing programs to support that level of complexity is not an effective use of time, and the reality is that the majority of the people who do write that way don't have the foresight or patience to actually write such a propgram correctly and it then causes headaches for others. sure, it may have worked for you in the past, but it is a naive approach and you don't have the luxury of writing all the programs when you work with a team. therefore, you can't assume they have read and understand every program you write in its entirety.

make your programs user/error-resistant by hiding what you can, and make them consistent with your team's style.

(there are technically a few additional benefits, which i'll not detail here)