4 ms·

I can certainly understand how that sentiment arose back in the dark ages of early operator-overloading abuse. I'm starting to wonder, however, whether the hor

by pohl 12y ago

I can certainly understand how that sentiment arose back in the dark ages of early operator-overloading abuse. I'm starting to wonder, however, whether the horror stories are continuing to propagate long after anyone has seen a real, living monster. If I'm browsing someone else's code today in a modern development environment and I encounter a function I don't know it's generally pretty easy to navigate to the definition (if it's in the codebase) or documentation (if it's not). If operator overloading is just a function with a name that happens to be a string of symbols and with infix application at the call site, can't I find out about it just as easily? What's the difference between myMysteryFunction(a,b) and a + b …if I know that the type of a and b isn't something ordinary like an int or a float?

redler 12y ago
Well, for me, the latter would masquerade as a trivial expression seen thousands of times, and which now may or may not have unexpected behavior. Every instance of something like a + b must now carry the slight extra cognitive load of potentially having a sort of "optional type annotation" in one's mind. Usually normal, but might not be. The former is at least potentially self-documenting. And even if it's a badly named function, at least you know it's a special function, and you know you'll have to go look up its behavior. [Edit: Clarity]
- vinkelhake 12y ago
  Done right, it should masquerade as a trivial expression seen thousands of times. There's a real advantage in being able to have user-defined types that have the same interface as native types. I want the ability to do 'a == b' regardless of whether it's a built-in or user-defined type. That's abstraction.
  - redler 12y ago
    That's a good point, and I agree. The situation I'm thinking of is something like, say, you have an object or type called a "Tire". It has width, diameter, weight, price, tread depth, compound, etc. As you work with Tires in your program, you frequently end up having to compare their widths. So you overload the ">" operator to return true if one Tire has greater width than another. Your code ends up festooned with these comparisons. Flash forward one year, you're long gone, and new developers on your team are left wondering which aspect of a Tire is used in comparisons with ">". Everything works, but it's easy to see how the ambiguity could lead to subtle submarine bugs; incorrect developer assumptions about the behavior of ">" may produce mostly -- coincidentally -- working code.
- pohl 12y ago
  I think I'd rather take that risk than have another scenario like BigInteger in Java: http://stackoverflow.com/questions/1783912/java-how-to-use-biginteger http://stackoverflow.com/questions/1783912/java-how-to-use-b...

by pohl 12y ago

redler 12y ago

Well, for me, the latter would masquerade as a trivial expression seen thousands of times, and which now may or may not have unexpected behavior. Every instance of something like a + b must now carry the slight extra cognitive load of potentially having a sort of "optional type annotation" in one's mind. Usually normal, but might not be. The former is at least potentially self-documenting. And even if it's a badly named function, at least you know it's a special function, and you know you'll have to go look up its behavior. [Edit: Clarity]

vinkelhake 12y ago
Done right, it should masquerade as a trivial expression seen thousands of times. There's a real advantage in being able to have user-defined types that have the same interface as native types. I want the ability to do 'a == b' regardless of whether it's a built-in or user-defined type. That's abstraction.
- redler 12y ago
  That's a good point, and I agree. The situation I'm thinking of is something like, say, you have an object or type called a "Tire". It has width, diameter, weight, price, tread depth, compound, etc. As you work with Tires in your program, you frequently end up having to compare their widths. So you overload the ">" operator to return true if one Tire has greater width than another. Your code ends up festooned with these comparisons. Flash forward one year, you're long gone, and new developers on your team are left wondering which aspect of a Tire is used in comparisons with ">". Everything works, but it's easy to see how the ambiguity could lead to subtle submarine bugs; incorrect developer assumptions about the behavior of ">" may produce mostly -- coincidentally -- working code.
pohl 12y ago
I think I'd rather take that risk than have another scenario like BigInteger in Java: http://stackoverflow.com/questions/1783912/java-how-to-use-biginteger http://stackoverflow.com/questions/1783912/java-how-to-use-b...