@Nicko: I have to confess that I really don't understand this idea that operator overloading somehow makes code harder to read
It's not a empirical fact. It's an opinion based on experiences of the language designers. You can certainly provide supporting evidence for either side, but ultimately the point is moot because Objective-C does not have operator overloading.
Can you honestly say that the former is harder to read than the later?
No, but I think it's beside the point. In any case, it's a very contained, tiny example which I don't think illustrates the thinking behind the decision.
In the example you give, you talk about the ease of writing code with operator overloading. In my opinion, ease of reading code is more important in most cases. The more layers you have, the more you have to dig to find out what's going on.
There's certainly less code to read in that one snippet, but shorter code doesn't necessarily mean more clear or easier. Cocoa and Objective-C discourages fancy language tricks and instead favors the shallow, low-tech solution. Something like Ruby/Rails takes a different approach. It's a choice: there's no way to prove one is better than the other.
It's called abstraction!
Hmmm. I'm not sure I agree with that. Redefining the basic meaning of a C operator is much different that creating a shim method over several smaller ones. But I could be convinced otherwise.
When you tackle a big chunk of code, it's already quite a lot of work to figure out the naming schemes and how all the classes fit together. It can become quite a bit more complicated if you have to figure out how the original author decided to recast operators. Again, this is just my opinion.
by Scott Stevenson — Sep 21
It's not a empirical fact. It's an opinion based on experiences of the language designers. You can certainly provide supporting evidence for either side, but ultimately the point is moot because Objective-C does not have operator overloading.
Can you honestly say that the former is harder to read than the later?
No, but I think it's beside the point. In any case, it's a very contained, tiny example which I don't think illustrates the thinking behind the decision.
In the example you give, you talk about the ease of writing code with operator overloading. In my opinion, ease of reading code is more important in most cases. The more layers you have, the more you have to dig to find out what's going on.
There's certainly less code to read in that one snippet, but shorter code doesn't necessarily mean more clear or easier. Cocoa and Objective-C discourages fancy language tricks and instead favors the shallow, low-tech solution. Something like Ruby/Rails takes a different approach. It's a choice: there's no way to prove one is better than the other.
It's called abstraction!
Hmmm. I'm not sure I agree with that. Redefining the basic meaning of a C operator is much different that creating a shim method over several smaller ones. But I could be convinced otherwise.
When you tackle a big chunk of code, it's already quite a lot of work to figure out the naming schemes and how all the classes fit together. It can become quite a bit more complicated if you have to figure out how the original author decided to recast operators. Again, this is just my opinion.