3 ms·
Well, let's assume that the "expected" behaviour holds, shall we? Let's open up a python REPL and try >>> 'caterpillar' * 2 'caterpillarcaterpillar' OK, n
by qayxc 4y ago
Well, let's assume that the "expected" behaviour holds, shall we?
Let's open up a python REPL and try
>>> 'caterpillar' * 2
'caterpillarcaterpillar'
OK, now for something different:
>>> [1, 2, 3] * 2
[1, 2, 3, 1, 2, 3]
Marvellous! How about this then:
>>> True * 2
2
Wait, what? Hm.
>>> False * 2
0
Whoops! Implicit type conversion takes place...
Even worse:
>>> 'abc' + 'efg'
'acbefg'
>>> 'efg' + 'abc'
'efgabc'
Now I'm stumped. Isn't addition supposed to be commutative?
So yeah, without contracts in place, operator overloading is BAD. You can never know what the operator does, or what its properties are by just looking at how it's used. There's simply no enforced rules and so no-one's stopping you from doing
>>> class Complex:
def __init__(self, real, imag):
self.real = real
self.imag = imag
def __add__(self, other):
return Complex(self.real - other.real, self.imag - other.imag)
def __repr__(self):
return f'Complex({self.real}+{self.imag})'
>>> x = Complex(1, 2)
>>> y = Complex(1, 2)
>>> x + y
Complex(0+0j)
Now this intentionally being malicious of course, but plenty of libraries overload operators in non-intuitive ways so that the operator's properties and behaviour isn't obvious. This is especially true if commutative operators are implemented as being non-commutative (e.g. abusing '+' for concatenation instead of using another symbol like '&' for example) or if the behaviour changes depending on the order of operands.
- salawat 4y agoJust give them the TL:DR, friend. If you didn't read it, you don't know. If you don't know, you have only yourself to blame when demons fly out your nose. Friends don't let friends spew demons out their nose.
- tialaramex 4y agoYeah, all the examples you give rub me up the wrong way. I don't like use of + for concatenate, even though it is present in Rust which I like very much on the whole. Here's what Rust tells programmers in core::ops (the sub-library whose safe Traits result in operator "overloading" for Rust). I put "overloading" in quotes because these operators just don't exist at all for your type if you don't implement the appropriate Trait. > Implementations of operator traits should be unsurprising in their respective contexts, keeping in mind their usual meanings and operator precedence. For example, when implementing Mul, the operation should have some resemblance to multiplication (and share expected properties like associativity).
- oefrha 4y ago> Isn't addition supposed to be commutative? No. Maybe crack open an introductory textbook to abstract algebra.
- adgjlsfhk1 4y agoCommon convention in abstract algebra is to use + only for commutative algebras (* is used for non-commutative ones as well as in rings).
- qayxc 4y ago> No. Maybe crack open an introductory textbook to abstract algebra Sources please! '+' is used as the standard operator for abelian groups.
- qayxc 4y agoYou know what, just for shits and giggles I actually DID open an introductory textbook on abstract algebra, just in case my undergraduate degree in maths failed me. Here's what the first chapter says about addition ('+') in Z: Here are 4 elementary properties that + satisfies: • (Associativity): a + (b + c) = (a + b) + c ∀a, b, c ∈ Z • (Existence of additive identity) a + 0 = 0 + a = a ∀a ∈ Z. • (Existence of additive inverses) a + (−a) = (−a) + a = 0 ∀a ∈ Z • (Commutativity) a + b = b + a ∀a, b ∈ Z. Also: Key Observation: There are naturally occuring sets (other than Z and Q) which come equipped with a concept of + and ×, whose most basic properties are the same as those of the usual addition and multiplication on Z or Q. I could go on with rings, fields, and vector spaces which also rely on the concept of addition as defined in Z, but I'm really curious to learn about addition being commonly used as a non-commutative operation, especially in the presence of an accompanying multiplication operation. edit: I forgot to provide proper references, so here's another example including a reference: When dealing with Abelian groups, it is customary to use additive notation. That is, the group operation will be called "addition," and we will "add" two elements rather than "multiply" them. We write g + h instead of g • h or gh, and ng replaces g^n. [Walker, Elbert A., "Introduction to Abstract Algebra", 1987; Ch. 2, Pg. 70]
- Gordonjcp 4y agoTrue and False are internally considered to be one and zero, so that example is correct. String concatenation is not addition. How would you expect commutative string concatenation to work? I guess, to boil it right down, what I'm asking is "do you understand what the word 'context' means?"
- qayxc 4y ago> String concatenation is not addition. Exactly! So why use the addition operator then? It's not as if alternatives (like the '&' I mentioned) aren't available.