Comments on: Bracket-notation syntax

By: Benjamin

Benjamin — Thu, 10 Sep 2009 20:35:54 +0000

I agree that operator overloading is objectively terrible.

By: Jim Dovey

Jim Dovey — Thu, 10 Sep 2009 20:08:19 +0000

I’d add a little something to the preceding paragraph in Benjamin’s last comment: “x = y + z” could be all sorts of different things. In C or Objective-C the possibilities are as listed above. In C++ (or Objective-C++) the possibilities are much larger, since any one of those could be a C++ object, any of which could have overridden = or + to perform different operations. In C++, you even get to implement different versions of those for different types.

I’ve seen plenty of C++ code where something went wrong because a compiler did something behind-the-scenes which resulted in a different operator method being called, and often the type error messages wouldn’t help at all. At least in ObjC with property syntax, the compiler can look at the property itself and point the user back to the property declaration. It can also enforce things like ‘readonly’ properties where a writer is defined inside the class for its own internal use— ‘[foo setValue: x]‘ would work, since -setValue: exists, but ‘foo.value = x’ would fail because the property is declared as readonly.

By: Benjamin

Benjamin — Mon, 10 Aug 2009 05:42:49 +0000

My problem is with appeals to “readability” that are arbitrary and ridiculous. Dot notation is unambiguous if you know the type of the variable preceding the dot. More importantly, if used correctly the intention of foo.value is pretty much the same whether foo is an object or a struct.

The arguments basically state that “foo.value” is confusing because, without context, you don’t know what it might compile to. That’s a useless metric, because nobody ever needs to evaluate a line of code without any context.

It’s about as valuable as arguing that “x = y + z” is confusing because you don’t know what machine instructions it will compile to, since x, y, or z could be any mix of char, int, float, long, double, long long, etc.

So, I’m not saying that opponents of dot notation are Luddites. I’m saying they are misguided. They are setting arbitrary boundaries for what’s “confusing” based on useless measures of “readability.”

By: Daniel Jalkut

Daniel Jalkut — Sun, 09 Aug 2009 04:38:02 +0000

(Meant to say “We’re NOT up in arms about blocks, for instance.”)

By: Daniel Jalkut

Daniel Jalkut — Sun, 09 Aug 2009 04:37:15 +0000

The nice thing about brackets in ObjC, is they are used in such an obviously distinct and unique manner from “vanilla C”, that there’s never any misunderstanding about what they mean.

In my opinion the only real reason dot notation in ObjC2 gets the push-back that it does is because it hijacks a notation that can be easily confused with the common C-language notation for a struct element offset.

So, if you want to argue for dot notation, argue on its merits. I don’t think your implication, that opponents of dot notation are merely luddites, is true.

We’re up-in-arms about blocks, for instance. The use of the ^ notation for blocks is handled in a way that makes it very unlikely to get an ambiguous reading of the programmer’s intention.

I think that the dot notation syntax was simply a mistake. I don’t fault the designers, it’s hard to come up with something that will stand the test of programmers, and how they actually work with the language. But hindsight is 20/20 and to me the dot notation’s problems outweigh its benefits.