4 ms·
But, this argument defeats itself. At least, in practice. If I look at how 'operator overloading' is used in practice, _rarely_ do you get commutativity, or ev
by rzwitserloot 8y ago
But, this argument defeats itself. At least, in practice.
If I look at how 'operator overloading' is used in practice, _rarely_ do you get commutativity, or even anticommutativity, associativity, or distributivity.
Take list addition, where operator overloading often shows up:
someList += someElement
is shorthand for:
someList.add(someElement)
add is not commutative; the elements used in the operation aren't even the same type.
The point being, the manipulation and simplification that is, according to GvR, much easier to spot if operators are used aren't even relevant here.
If we're talking about, say, introducing a class 'Complex', representing complex numbers, and wishing that the language is such that one can add the ability to use mathematical operators here, observing that it is both [A] common in the domain of complex numbers to use, say, the symbol `+` to indicate addition, and [B] these properties of operations such as commutativity apply to many mathematical operations one might want to perform on complex numbers, I'd agree: Yeah, the language kinda sucks if you can't write `Complex(a, b) + Complex(c, d)`.
But how often does that actually occur?
Separately, if you go down this route, the abstraction should be as complete as it can be. Therefore, this:
`Complex(2, 3) + 5`
Should work, and should evaluate to `Complex(7, 3)`. But.. this:
`5 + Complex(2, 3)`
should also work. Which requires either scala's `implicit` system or python's take on this, involving `__rplus__`. These operations introduce their own complications.
Thus, the debate on operator overloading boils down, as language feature debates usually do, as a cost v. benefits analysis. The costs are heavy: There is a lot of proof out there that even experienced coders just insist on abusing operator overloading (or, to be a bit less judgemental: That opinions are rather divided on how they ought to be used, given the amount of complaints about `cout << somestring` and the like). Also, the language complexity is considerable, given that you need to solve the `5 + Complex(2, 3)` problem.
Are the benefits worth it? Possibly.
But I don't think GvR's article takes the cost side seriously, and the benefits stated, at least in my experience, tend not to apply at all there where op overloading tends to end up.
- Sharlin 8y ago> But.. this: > `5 + Complex(2, 3)` > should also work. Which requires either scala's `implicit` system or python's take on this, involving `__rplus__`. These operations introduce their own complications. Or the way C++ handles this: being able to define operators as free functions (though you could alternatively define an implicit conversion).
- ddragon 8y agoMultiple dispatch languages like Julia handle that example fairly easily: +(x::Real, z::Complex) = Complex(x + real(z), imag(z)) +(z::Complex, x::Real) = Complex(x + real(z), imag(z)) And you can call it in both infix or prefix forms. Though Julia is a math focused language and the community tries to stay consistent with the correct notation. You can't add an element to a list using the "+" operator, but you can add each element of two lists if their dimensions match.
- lozenge 8y ago`someList += someElement` raises an exception. It's `someList += someSequence` which just does the same as `list.extend`, that is, `someList = someList + list(someSequence)`
- jacobolus 8y agoI mostly get stuck using Javascript because I want to target people’s web browsers. I write a pretty good amount of numerical code. The lack of operator overloading for number-like objects is extremely annoying for me. There are always hacky workarounds, e.g. https://github.com/enkimute/ganja.js#the-inline-function https://github.com/enkimute/ganja.js#the-inline-function but in this particular case the code to make it work ends up a bit confusing, and the hack is somewhat brittle and inflexible.
- wozer 8y agoIn my opinion, requiring commutativity from a +-operator is maybe too much. Associativity and a neutral element seem to be enough (i.e. forming a monoid).
- maweki 8y agoI think that just shows that the python language and some others la k another operator and not that + should not be commutative.
- naniwaduni 8y agoIt seems like + normally connotes a commutative operator; for general monoid operators are normally notated as if they were multiplications.
- enriquto 8y ago> requiring commutativity from a +-operator is maybe too much The + operator is the only one that can be realistically required to be commutative. All other operators need not. If we are to have any commutative operator, it should definitely be +.