The + operator is not commutative in Pike; see predef::`+() in the refdoc. (It was considered commutative in 7.0; Pike could change the order back then.)
Just a detail -- but I believe you are talking about associativity here, rather than commutativity:
(a+b)+c == a+(b+c); // associativity a+b == b+a; // commutativity
/ rjb
Previous text:
2003-04-18 00:53: Subject: lfun::`+=()
There is an obvious difference between mathematical addition and the + operator in Pike. It's only the latter that's interesting here.
The + operator is not commutative in Pike; see predef::`+() in the refdoc. (It was considered commutative in 7.0; Pike could change the order back then.)
The + operator is also not destructive on either argument in Pike. The refdoc says that implicitly since the reverse always is documented (or at least it should be).
So given that one should not make an lfun that causes predef::`+ to go against its documentation then the expected behavior of the lfun `+ is fairly well documented. Granted, it could be documented better for the lfun too.
There's no need to figure out if an expression a+b is destructive, since if it is then Pike ensures that the destructivity doesn't have any side effects, under the assumption that the lfuns are correctly implemented. The lfun `+= only works as a more optimized alternative to `+ that Pike can use in that case. If one _have_ to figure out which of the lfuns `+ and `+= that are called in a certain case then they aren't implemented right.
Perhaps it'd be better if `+= had another name, say `destructive_add, so that it wasn't confused so easily with the += operator.
I see that `+= lacked documentation. I've fixed that now.
/ Martin Stjernholm, Roxen IS