One of the perennial topics in the Mac developer community is that on whether dot syntax is a good idea. Reading through blog posts and twitter feeds an unfamiliar observer would deduce there that this is a Marmite issue: you either love it or hate it.

The problem is a lot of people familiar with the topic also see it as that, but the truth is quite different and there are some subtleties in the argument, particularly the dislike camp of which I am a member, that are often over looked. I'm hoping this blog post will give a better idea of why people, or at least I, dislike dot syntax.

History/Programming Lesson

For those unfamiliar with it (or those who don't program) I'll give a brief history and overview of the technology that causes the problem. Feel free to skip this section if you are already familiar with this tale.

In object oriented programming (OOP) you store variables (containers for data) within classes (containers for variables and methods, or actions upon that data). One of the key concepts is encapsulation, which means that these classes are black boxes and you cannot directly access the variable, but instead have to call a method to get to the data. Think of this as a bit like a cash machine, where you don't directly get the money, but instead use an interface to ask for the money and then receive it. These sorts of methods go under many names: accessors, getters and setters, properties etc.

In versions of Mac OS X prior to 10.5 writing these methods required writing a lot of code that is almost identical for each variable. For example, the code for accessing the variable foo would be:

//Header
- (id)foo;
- (void)setFoo:(id)newFoo;

//Implementation
- (id)foo {
    return foo;
}

- (void)setFoo:(id)newFoo {
    if (foo != newFoo) {
        [foo release];
        foo = [newFoo retain];
    }
}

There are many variations on these methods but they all do the same thing, either return the contents of a variable, or replace the contents with a new piece of data.

You can probably tell that writing that over and over can get tedious, when there are only minor differences you can make, usually in memory management or thread safety. So in Mac OS X 10.5, Apple introduced Objective-C 2.0 which featured, amongst other things, properties. This allowed the simplification of the above code to:

//Header
@property (retain) id foo;

//Implementation
@synthesize foo;

Much simpler. It also adds extra information that wasn't previously there, such as the type of memory management used and whether it is thread safe or not.

Now while this brought almost universal praise, Apple also introduced a new syntax for accessing these properties: dot syntax. This allowed programmers to use properties in a different way:

//Standard way
variable = [object foo];
[object setFoo:variable];

//Dot syntax way
variable = object.foo
object.foo = variable

Implementation vs Idea

For the purpose of explaining why people feel a certain way about dot syntax in Objective-C it is important to distinguish between implementation and idea. In this case, dot syntax is the implementation. The idea is a simpler way to use properties. A lot of the complaints are not with the idea, but with the implementation.

Another example of this in Objective-C 2.0 is garbage collection (automatic memory management). There are a lot of people who are wary of using garbage collection. Some are wary because they are used to the idea that garbage collectors are much slower and less efficient than manual memory management (in most cases the opposite is true with the Objective-C garbage collector), but this stigma of the idea of garbage collection remains.

Then there are people who are wary of the implementation. They feel that it is a major commitment to something that is relatively untested. I had a discussion a few days ago where a programmer started writing a garbage collected app and then found a bug with no work around other than "wait until Apple fixes it", so he had to go back through his code and switch to manual memory management.

In this case this is a complex piece of technology that is quite new and can seriously harm your project's shipping date if you encounter a bug with no work around. Now before people get the idea that I'm anti-garbage collection, I'm not. I'm using it in Minim 2.0, but this is only because it has been around for 2 years now, and many bugs have been fixed in updates to OS X 10.5. The garbage collector in Objective-C is great, it is just a 1.0 release.

Anyway, enough with the small detour into garbage collection, that isn't the main topic of this post. However, it has offered us a good example of why someone may dislike an implementation, one that is different to why most developers dislike dot syntax. Developers are wary of garbage collection because it is new. Developers dislike dot syntax because they believe it is flawed.

Why Dot Syntax?

There are many reasons one can suggest for why Apple chose dot syntax. The most obvious is that it is somewhat similar to how other languages work. Whereas Objective-C uses [object method] to run a piece of code, lots of other languages use object.method(), and some even allow identical object.property = newvalue syntax for variable access.

It is this familiarity that may help programmers move from other languages. Unfortunately this isn't necessarily the case. Dot syntax is inconsistent, working for methods that aren't properties. It also can cause confusion between objects and C structs (more on this later). I have seen several new programmers get confused by this, as they can use dot syntax for certain methods, but not for others. There are even pro-dot syntax developers who agree that it shouldn't necessarily be taught to new Objective-C programmers until they have got a good grasp of the language.

Now there is an argument against those of us who are anti-dot syntax, that we are simply Objective-C old hands who are opposed to change. This isn't the case. There are many people who have been using Objective-C since before Apple had anything to do with it who are using dot syntax and there are those who only started with it a few years before dot syntax arrived that dislike it. I only started programming in Objective-C 5 years ago, not exactly an old hand when you consider Objective-C is over 20 years old.

The other reason why this isn't true is that these programmers embrace all the other changes. They use properties and fast enumeration and garbage collection. They use new APIs and new tools. A lot of these "luddites" who are supposedly opposed to change are actually the ones at the forefront of change. The difference is that change can be for the worse or for the better, and while they believe most of Objective-C 2.0 is change for the better, dot syntax is change for the worse.

State vs Action

Now one argument for the idea of a separate syntax for property access is that it helps separate state and action. This is quite useful in places as you can tell when state will change, which is useful for many things, but importantly thread safety. For the most part I agree with this, but I believe there are issues.

The biggest is simply an issue of how you conceptually view your program working. Those who are fully behind the state vs action system see [object doSomething] and object.property as different things. One is performing an action, one is accessing state. I see things at a more abstract level, where both those are simply sending a message to an object, so they are identical in what they do. This is somewhat anal, but it is how quite a few developers feel.

Structs

I made a tweet that proved to be quite controversial, saying that I thought developers who think dot syntax is a good idea don't do much UI coding. The reason behind this idea is that UI coding requires the usage of C structs. A struct is a simple container for several pieces of data, and in some ways is a sort of lightweight class. It is because it is lightweight that it is used all over the UI side of Cocoa for defining rectangles, sizes and points.

So what is the issue? Well this is how you access a struct:

variable = struct.field;
struct.field = variable;

Looks familiar, doesn't it? This is the biggest issue, the fact that struct and property access is identical. If you look at the following, would you be able to tell me which is the struct and which is the property?

a.b = foo;
c.d = bar;

Of course that example is a bit contrived so let us look at something that you may actually find in Cocoa:

rect = controller.view.frame;
rect.size.x = 10;
controller.view.frame = rect;

Now an experienced Cocoa developer could tell you that controller and view are objects and rect and size are structs, but someone new to Cocoa couldn't tell the difference.

Of course we could just get rid of structs and use objects for everything, couldn't we? Unfortunately no. Structs are relatively lightweight when compared to objects, so are ideal for tasks such as defining a rectangle when you only need to collect 4 values into 1. You don't need all the unnecessary cruft of creating an object, so it makes your code faster and your memory usage smaller (granted these aren't as big an issue with modern computers, but there is no point slowing things down).

The other issue is that Objective-C is also C. Anything valid in C is valid in Objective-C, and structs are part of C. There is no getting rid of them. You could get rid of them from Cocoa, but you would still be mixing object.property with struct.field.

Of course this confusion can potentially be dangerous. struct.field is simple memory access/assignment, you cannot make it do more. However, object.property isn't necessarily just memory access/assignment (technically it almost never is). There could be file access, network access etc. happening under the hood, but you see the same thing. This confusion can be potentially damaging.

[UPDATE] Note, that while I mention object.property, I don't imply that accessor methods will be doing resource intensive tasks, but the fact that dot syntax isn't limited just to properties means that object.method could be used and would be computationally intensive.

Conclusion

So what is the solution. Well as I said earlier, most developers don't have an issue with the idea of a different syntax for property access, the issue is with the implementation. The solution would have been to not overload the . character. There are many other ways that property access could have been done and most of the arguments above vanish if a different character is used. Why not foo~bar, foo•bar or foo@bar. None of those characters are used in binary operations in C or Objective-C.

The important point is, those who are against dot syntax aren't simply the old school who don't like change. They like change, they embrace change, but they just feel this is a change for the worse. You may feel differently about the syntax, but there are many significant cons to the current implementation, which is why there will always be those who dislike it. And all of those cons revolve around one character.

Comments (8)

---

Page 1 of 1 pages