Do I need ARC keywords for properties that I don't synthesize?

Question

I have a property that I do not synthesize, instead I create a getter and setter myself. Therefore, the ARC keywords (strong or weak) have no meaning, I assume, so I eliminate them. This works fine on Xcode 4.3, but when my coworker opens them on XCode 4.2 the compiler complains that there is no strong/weak keyword, so I instructed him to meaninglessly enter the keyword back in again. Which is correct (with or without keywords)?

To be clear: I have a property like this @property (nonatomic) NSString *foo and in the .m file I implement -(NSString *)foo and -(void)setFoo:(NSString *)foo and do NOT include @synthesize foo. Another relevant detail is that there is no corresponding iVar, instead the properties interact with a Core Data object. This will not compile in XCode 4.2 unless I add strong or weak to the keywords.

EDIT I thought of one more relevant thing, one of these properties is on a Protocol, I don't know if that makes a difference.

Navvy

Answer 1

The declared attributes that you are referencing are optional. To quote the documentation:

Property Declaration and Implementation
The @property directive declares a property. An optional parenthesized set of attributes provides additional details about the storage semantics and other behaviors of the property - see “Property Declaration Attributes” for possible values.

Property Declaration Attributes
You can decorate a property with attributes by using the form @property(attribute [, attribute2, ...]). Like methods, properties are scoped to their enclosing interface declaration. For property declarations that use a comma-delimited list of variable names, the property attributes apply to all of the named properties.

If you use the @synthesize directive to tell the compiler to create the accessor methods (see “Property Implementation Directives”), the code it generates matches the specification given by the keywords. If you implement the accessor methods yourself, you should ensure that it matches the specification (for example, if you specify copy you must make sure that you do copy the input value in the setter method).

If you then use @dynamic instead of @synthesize it is telling the compiler that you will be writing your own methods and prevents it from complaining when it doesn't find suitable methods.

More information can be found here.

Waterlogged

Interesting...I will try adding a dynamic and see if it works on XCode 4.2 – Navvy

Answer 2

borrrden,

First, why do you care to elide your memory policy in your property statement? It announces to consumers of your class what the policy is. Don't you want them to know?

Second, the @synthesize is not a nop. It is the mechanism by which the language support KVO. While you may not be using that now, why would you preclude this use for the future.

Frankly, by not using a full description in @property nor using @synthesize, you are, IMO, engaging in premature optimization. Your current design doesn't save you message dispatches and forces you to manage, if necessary, the creation and typing of ivars. And you are losing features of the language.

Unless you have a good reason to get outside the bounds of the preferred Obj-C v2+ patterns, and you haven't listed those, then I would return to using the standard pattern. Then your problem just goes away.

Andrew

Goddaughter

There are very often good reasons to write your own methods. (Such as calculated properties, validation, etc.) – Waterlogged

@synthesize has nothing at all to do with KVO. You can use KVO without ever writing @synthesize and while providing your own custom setters and getters. – Rude

It is not about optimization, it is about logic. There are no iVars for these properties The properties interact with Core Data objects by in turn setting their properties. In this case do you consider them to be strong or weak? Perhaps the same as the subsequent object property that I am setting. I don't mind writing them in as long as I am not causing any side effects. – Navvy

Core Data ivars are all strong. I only use weak when I have a specific reason to do so. I call this setting retainership. If I am likely to need something then I retain it. If it then causes a retain cycle I make it weak. And I think this is an engineering problem and not a logic problem. Engineering is partially about code maintenance. Obj-C is a mostly self documenting environment. Don't weaken it by removing property markers. BTW, I think the default @property memory policy is strong. Eliding it doesn't change the compiler's behavior. IOW, you've made your code opaque -- to what end? – Goddaughter