Did you find it strange somehow? Odd perhaps? Then you may be surprised to learn that this is perfectly valid Objective-C code. Go ahead and try it in your project. As long as the project is set to use the Apple LLVM Compiler this will work.

As you can see, you can write any message sent to an object (ie init) and any message sent to a class (ie alloc) with dot notation, effectively treating the method like a readonly property. This is a feature of the Apple LLVM Compiler.

I’m not sure if this behavior it is documented or not, but it’s definitely a side-effect of Objective-C properties that are implemented more generically in the Apple LLVM compiler than they were in the LLVM GCC compiler. We’re now allowed to use dot notation for many methods. There are only two rules to consider.

The first rule is that dot notation does not generally work for all methods that receive parameters. For example you can’t use dot notation with initWithString: – that wouldn’t even work syntactically:

The second rule is that there are methods with parameters that are allowed to be used with dot notation – if that method is defined like a property setters and begins with “set” and the capitalized name of the property. That means the setter of “number” would have to be “setNumber” in order for you to assign a value to number using dot notation.

So if you have a class that defines this setNumber: method but number is not a @property of the class (nor @synthesize’d nor @dynamic), you can still use dot notation to assign a number:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

@interface MyClass : NSObject

-(void) setNumber:(int)number;

@end

@implementationMyClass

-(void) setNumber:(int)number{

NSLog(@"number is: %i",number);

}

@end

// in some other class

MyClass*myClass=[[MyClassalloc] init];

myClass.number=10;// allowed, even though number is not a property

intnumber=myClass.number;// ERROR, no getter method for number in MyClass

Effectively this makes number a write-only property of MyClass. That’s something that you can’t normally do with Objective-C properties. For good reason I might add, since if you can store a value in an object anyone would rightfully assume that it is valid to read the value as well.

Where dot notation fails unexpectedly

One case I mentioned just above, although I haven’t encountered one yet there’s a slim chance you might run into the occasional write-only property. The compiler will give you a “Expected getter method not found on object of type …” error in that case.

There are also some rare exceptions that really should work, but don’t. For example this is one I encountered:

1

2

Classc1=str1.class;// ERROR

Classc2=str1.superclass;// works fine

For some reason using dot notation with the class message spits out a “Expected unqualified-id” error. This is likely because class is a reserved keyword, and Xcode actually highlights class in the same color as @interface, return, self or super.

My guess is that technically it would work on the compiler-level, but the parser says “no, no, that can’t be right, class is a reserved keyword”.

When to use dot notation

I’m not suggesting that you use dot notation everywhere you can. I’m aware this is a highly subjective issue, since at the machine code level both [str1 copy] and str1.copy will generate the exact same instructions. They’re virtually identical, so it boils down to a matter of preference regarding code style.

My recommendation is to use dot notation wherever the message name indicates that it is some kind of a passive property of the object rather than running complex code. Methods like capitalizedString, length, count, intValue, hash, description, lastPathComponent, isAbsolutePath are all great examples of should-be-properties.

I do agree with you if you find the following rather odd:

1

NSString*str=NSString.alloc.init;// odd, avoid doing this

I could get used to it but I wouldn’t recommend using dot notation for object allocation and init because in many cases you will be using some variant of initWithXXX. So then that would become a mixture of dot notation and old-school messaging:

1

NSString*str=[NSString.alloc initWithString:@"x"];// YIKES!

Where I can recommend to use dot notation indiscriminately is with singletons. Consider this:

1

2

3

4

5

CCDirector*director=[CCDirectorsharedDirector];

CCDirector*director=CCDirector.sharedDirector;

NSFileManager*fm=[NSFileManagerdefaultManager];

NSFileManager*fm=NSFileManager.defaultManager;

Dot notation makes working with singletons less brackety and I think more natural, too:

1

2

3

4

CCDirector.sharedDirector.animationInterval=1.0/60.0;

CCDirector.sharedDirector.displayStats=YES;

if(KKInput.sharedInput.touchesAvailable){..}

NSLog(@"%@",UIDevice.currentDevice.name);

Why dot notation is preferable

Unless you’ve been programming objectively for many years, it shouldn’t be too hard to let go of some of those square brackets. Personally after 3 years of working with Objective-C I’ve totally become accustomed to using square brackets. However they do get in the way frequently, especially when Xcode messes things up.

A typical example revolves around writing a line of code, adding a square bracket at the end, only to realize that Xcode added the opening bracket to the wrong statement. Typically Xcode adds brackets at the beginning of the line:

1

2

3

4

5

6

7

8

9

10

11

// what I wrote:

[label setString:messagecapitalizedString];

// what Xcode thinks I wanted after adding a second square bracket at the end:

[[label setString:messagecapitalizedString]];

// what I really wanted:

[label setString:[message capitalizedString]];

// how dot notation makes ugly crap like this totally natural:

label.string=message.capitalizedString;

How dot notation can make your code more readable

In some cases dot notation can make previously mixed dot notation and bracketed lines of code to uniformly dot notated code, which I think is a lot better to the eyes:

1

2

3

4

5

6

7

8

9

// previously on We Love Brackets:

intwidth=[node.parent texture].contentSize.width;

// or some variation thereof, like:

intwidth=[[node.parent texture] contentSize].width;

intwidth=[[node parent] texture].contentSize.width;

intwidth=[[[node parent] texture] contentSize].width;

// … and now the conclusion:

intwidth=node.parent.texture.contentSize.width;

Ah, what a relief! Go ahead and try it yourself. Dot-notate the crap out of Objective-C, I dare you!

Dot notation for non-properties considered a blessing!

Dot notation is shorter, less noisy on the eyes, and can be applied more consistently if you’re working with C structs frequently (ie CGPoint, CGSize, etc.).

Moreover – at least for european users – the dot is a single key on the keyboard whereas either square bracket requires to hold down a modifier key while typing it. And if you’re anything like me (ie human), then you’ll know the pain associated with accidentally typing { and Xcode autocompleting that with a closing } or some other autocompletion “Not no, dammit!” insults.

I definitely see a great appeal to this for programmers new to Objective-C (specifically with C# or Java backgrounds), as they don’t need to expose themselves to “weird square brackets” just as often as has been the case in the past years. This should make transitioning easier.

What do you think about dot notation? Are you going to adopt it, or stick with square brackets?

I very much enjoy the learning process, the pushing of boundaries (mine and yours and that of technology), having the freedom to pursue whatever is on my mind, to boldly program what no one has programmed before, and to write about what I've learned. Help me help you by browsing the products in the Learn Cocos2D Store.

For me, there’s a big difference between the dot notation and square brackets!
Dot notation is for accessing a value or a method while square brackets are specific in Obj-C for sending messages.
If you start using dot notation everywhere, you’ll start mixing between calling functions and settings values. Please correct me if I’m wrong 😉

Will do. You’re wrong. 😉
int i = object.property;
is the same as
int i = [object property];

Accessing a property sends a message to the property getter. And assigning a value sends a message to the property setter:
object.property = 10;
is equivalent to
[object setProperty:10];

The only difference between the two variants is syntactical. Technically they both do the exact same thing. The interesting part is that for dot notation to work you no longer have to have declared the getter and setter as a @property.

I could understand you if you followed the unspoken rule of never having side effects in property accessors. I.e. if your properties never contain any more code than “return i-var” and “if (ivar != argument) ivar = argument”, effectively.
With following that rule, you could then use the dot notation only for accessing such properties, and it would help documenting your code in the way: “this invocation only sets or read an i-var, nothing more”. Then, yes, your argument is valid.

However, most code I’ve seen doesn’t follow this rather clear rule and employs side effects in properties freely. Then your distinction isn’t helpful any more, since the property accessors behave like any other custom-written method, and so there’s no use in using dot notation for one and messaging for the other type.

Good point. I just tried it with Xcode 4.3.3 and typing CCDirector.sharedDirector does not offer sharedDirector in autocompletion. But once you’ve typed that it does offer the director properties for autocompletion, like displayStats or animationInterval.

On most european keyboards the square brackets are on the 8 and 9 keys, and you have to hold down Control or Alt (not sure which is which because I’m using a windows keyboard with remapped Cmd, Alt, Ctrl buttons). On Windows systems you have to press AltGr+8 and AltGr+9. Interestingly on a german wireless Mac keyboard the [ and ] characters aren’t even printed on the keys.

Wow, this really different!
I’m a little afraid of the C++ look of it. I’ve spent time learning Objective C and never really liked the bracket syntax. Years of C and C++ make the brackets look wrong to me. Now I fear I’ll start doing this and mis-use the language. I’ll be very interested to hear of any long term pitfalls that may come to light

Dot notation is meant for properties. So it’s perfectly fine to use it as a shortcut to a method that returns a property (a noun). However, never use it for a method that describes an action (a verb). I think this is what you meant when you referred to the do’s and don’ts. It’s not a matter of underlying complexity, but a matter of semantics. Design deals with semantics. It doesn’t care about computing complexity.

In short:
alloc = a verb –> no no
init = a verb –> no no
copy = a verb –> no no
capitalizedString = a noun –> yeah!
description = a noun –> yeah!

While I am very inclined to agree with you also, alloc and init feels pretty good in practice compared to the nested brackets approach typically recommended.

Since both return a Related Return Type (instanceType), we could assume them to return a “noun” of sorts. Ok I’m pushing I know but I like the idea of Class.alloc.init returning a standard object and saving the extra brackets in a call to [Class.alloc initWithGoodies:goodStuff]. Looks cleaner than [[Class alloc] initWithGoodies:goodStuff] to me.

I love objective c but I have to add that I have no Smalltalk experience, so maybe I’ve been tainted by the Java and C# approach over the years. I’m pretty satisfied though with brackets and have fully adjusted to this style of messaging.

One counterargument is that there should be no conceptual difference between the two methods from the perspective of a caller. In other words, one shouldn’t know or care whether or not -randomName is just a getter that returns an internal variable, because that’s an implementation detail of the class.

I have mixed feelings about dot syntax because of that exposure of class details.

About Me

I started my game industry career in 1999 creating Gameboy titles as designer, followed by working as software engineer on RTS/RPG series SpellForce and BattleForge for a studio that was acquired by EA in 2006.

Since 2010 I'm a freelance developer, specialising on 2D game development for mobile.

Try out TilemapKit!

TilemapKit is the complete solution for tilemap game developers. Click an image to learn more!

Iso Map rendered by TilemapKit

Ortho Map rendered by TilemapKit

Hex Map rendered by TilemapKit

Steffen's Books

The iOS Action RPG Engine

Rapidly create your own RPG or action-adventure game with this complete starter kit. Includes an ebook, game source code and a royalty-free art package.More Affiliate Products …