Autosynthesis / I’m Really Into This / Everybody Happy When We Write Less Code

by Joey deVilla on September 29, 2012

In an earlier post, I talked about a couple of changes to Objective-C that should reduce the amount of “yak shaving” you need to do while coding: syntaxes for NSNumber, NSArray and NSDictionary literals, as well as the new, shorter syntaxes for NSArray/NSMutableArray and NSDictionary/NSMutableDictionary item access.

Here’s the tl;dr version of this post: you no longer have to @synthesize properties! (Most of the time, anyway.)

From Public Variables to Getters and Setters to Properties

In the early days of object-oriented programming, you were supposed to make a class’ public attributes accessible through public variables. Access was pretty simple:

Then, it became a better idea to lock away all the variables and use getters and setters:

It does the job, but it’s a little clunky.

Nowadays, the preferred way to expose class attributes in a number of languages is through public properties. With them, we’re back to accessing object attributes through this simple syntax:

What @synthesize Was For

Creating properties in Objective-C classes used to require statements in a couple of places. For a public property, you had to declare it in the interface (.h) file:

The @property statement tells the compiler that you want to expose a property; in the case of the code above, the name of the property is speed. Properties are by default both readable and writeable. If you like to spell everything out very explicitly, you can by declaring the property this way:

If for some reason you wanted speed to be read-only, you can declare the property this way:

With every property declaration comes the need for the underlying instance variables — ivars in Objective-C parlance — and the requisite getter and setter methods, which go in the implementation (.m) file. All this setup for each property can get a little tedious, and the @synthesize statement saves you from that tedium. Instead of having to declare the corresponding ivar and write those methods, @synthesize lets you do all that in a single line of code:

By default, the name of the ivar created by @synthesize was the name of the corresponding property preceded by an underscore character. For example, the default name of the ivar behind a property named speed would be _speed. If you preferred, you could specify a different ivar name this way:

The general rule was that if you only needed a simple getter and/or setter for a @property, use @synthesize.

Introducing Autosynthesis

The version of CLang (the Objective-C compiler) that comes with XCode versions 4.3 and later (the latest version is 4.5), supports autosynthesis, which automatically does the synthesizing for any class properties you declare in the header. If your @property needs only a simple getter and/or setter, you don’t need to have a corresponding @synthesize anymore. The compiler takes care of that for you.

Properties with autosynthesis work like they did with manual synthesis. You access them using the self.propertyName syntax, and the name of the ivar that gets generated is still the name of the property preceded by an underscore character.

Cases Where @synthesize is Still Useful

There are some cases where you’ll still want to use the @synthesize keyword, and this article in the blog Use Your Loaf does a good job explaining these cases. Such cases are a little more rare; most of the time, you can simply skip added @synthesize to your code because the compiler’s taking care of that for you!

In Case You Were Wondering…

The title for this article comes from the chorus of Shriekback’s 1985 alt-dance number, Nemesis:

Priests and cannibals
Prehistoric animals
Everybody happy as the dead come home

Leave a Comment

{ 1 trackback }

Previous post:

Next post: