a + d = e (1 + 4 = 5 = e) b + e = g (2 + 5 = 7 = g) c + f = i (3 + 6 = 9 = i)
I think he was making a joke about how + with strings doesn't necessarily mean string concatenation.
a + d = e (1 + 4 = 5 = e) b + e = g (2 + 5 = 7 = g) c + f = i (3 + 6 = 9 = i)
I think he was making a joke about how + with strings doesn't necessarily mean string concatenation.
If in your language, + means string concatenation by convention, then + darn well means string concatenation. If in your language + means "contextually appropriate depending on what arguments you pass to it", then
"abc" + "def" => "egi"
doesn't strike me as obviously wrong.
More broadly, consider a language in which we teach initiates that "Plus adds things in the way you'd expect!"
map = {}
map2 = map + {"key" => "contents"}
What are the contents of map and map2 now? Uh oh. More worrisome:
map = MemcachedWrapper.new
map2 = map + {"key" => "contents"}
What just happened?
Avoiding operator overload doesn't avoid poorly named methods, nor does it avoid the need for documentation. All that it does is force programmers to do ugly things when dealing with math, and there is a lot of math-based programming out there.
1) I did say 'savvy'. Sort of because I don't get to use that word enough, but also because it is possible to abuse operator overloading. String concatenation with the addition operator isn't going to suprise anyone, even if you come from another language (well, it might, but the choice of the + operator isn't an unintuitive one). Furthermore, nobody's jumping at things with well-defined operators, like vectors/matrices, etc. I've written very little outside of a maths library that used operator overloading, but it's a godsend for the cases where it's appropriate... probably a truism.
Secondly, they're just functions. You can look them up (y'know, assuming you can), you can optimise them, and you can document them. A programmer encountering an operator doesn't have to rely on their interpretation alone, and indeed shouldn't. They should know what that operator does. Now of course, if the operator has absolutely no contextual reason for existing, or is suprising divergent from its apparent purpose... well, see point 1.
As for your example, how do you do a greater-than-or-equal comparison on strings? :D