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.
If + silently gets translated to adding 2 numbers or joining 2 strings that is operator overloading, no matter how it's done under the hood.
If python had you write
e1.__add__(e2)
Or
S1.__join__(s2)
Then you would have 2 distinct operators, therefore no overloading.
Re classes.
Foo.len() and bar.len() are different. You can tell that when you are using them.
It's no different to
I_add() and f_add() they are both different functions.
If you automatically called one of those depending on whether the arguments were floats or ints, that would be overloading.
I suppose you could take it further and say that it's overloading if you have different int sizes.
But then we don't really class that as overloading, which I suppose demonstrates that it isn't a very precise term so there isn't much point getting particularly pedantic about it.
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_.
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.
If python had you write e1.__add__(e2) Or S1.__join__(s2)
Then you would have 2 distinct operators, therefore no overloading.
Re classes.
Foo.len() and bar.len() are different. You can tell that when you are using them.
It's no different to I_add() and f_add() they are both different functions.
If you automatically called one of those depending on whether the arguments were floats or ints, that would be overloading.
I suppose you could take it further and say that it's overloading if you have different int sizes.
But then we don't really class that as overloading, which I suppose demonstrates that it isn't a very precise term so there isn't much point getting particularly pedantic about it.
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_.
"self" aged well.