So the `+` is not _overloaded_, the `+` syntax is a shorthand for calling a method named `__add__` on the value of the first operand, with the value of the second operand as an argument . That is: `e1 + e2` is syntactic sugar for `e1.__add__(e2)`, no more and no less.
It's not "operator overloading" any more than two _different_ classes having a `length` property is "length overloading".
Using the term "operator overloading" to begin with is the error here.
Good introduction to the space in Python (although a lot of languages have it, and just as many disallow it). I'm still on the fence regarding how useful or confusing it is. without (or even with) good variable names, "a + b" is an absolute mystery, especially when handling objects that come from classes you have no detailed internal understanding of.
I feel like it is on you to understand these classes first though. In game engine programming, operator overloading is often just vector algebra. If you have no idea how matrix-vector multiplication works, then you have no business doing those things anyway, overloaded operator or not. But if you do understand it, it makes your code infinitely more readable than without overloading. And everyone with a math education will also understand that aspect of your code, no matter if they are familiar with your usual paradigms.
Agda has the most wonderful (terrifying?) operator syntax I know of. Any Unicode (except for a few reserved words) can be used, and you can indicate where operandi go with an underscore. For instance defining a function named _•_ would allow you to use a • b.
But there is no limit to where the underscores go: the name _? Would give you x ? postfix. To define if-statements one defines the name if_then_else_.
So the `+` is not _overloaded_, the `+` syntax is a shorthand for calling a method named `__add__` on the value of the first operand, with the value of the second operand as an argument . That is: `e1 + e2` is syntactic sugar for `e1.__add__(e2)`, no more and no less.
It's not "operator overloading" any more than two _different_ classes having a `length` property is "length overloading".
Using the term "operator overloading" to begin with is the error here.
Good introduction to the space in Python (although a lot of languages have it, and just as many disallow it). I'm still on the fence regarding how useful or confusing it is. without (or even with) good variable names, "a + b" is an absolute mystery, especially when handling objects that come from classes you have no detailed internal understanding of.
I feel like it is on you to understand these classes first though. In game engine programming, operator overloading is often just vector algebra. If you have no idea how matrix-vector multiplication works, then you have no business doing those things anyway, overloaded operator or not. But if you do understand it, it makes your code infinitely more readable than without overloading. And everyone with a math education will also understand that aspect of your code, no matter if they are familiar with your usual paradigms.
Agda has the most wonderful (terrifying?) operator syntax I know of. Any Unicode (except for a few reserved words) can be used, and you can indicate where operandi go with an underscore. For instance defining a function named _•_ would allow you to use a • b.
But there is no limit to where the underscores go: the name _? Would give you x ? postfix. To define if-statements one defines the name if_then_else_.
This aged well
No, no, TFA is about python:
"self" aged well.