On 18.09.2024 at 00:13, Rowan Tommins [IMSoP] wrote: > Since you mentioned Scala, I looked it up, and it seems to be on the > other end of the spectrum: operators are just methods, with no > mathematical meaning or special dispatch behaviour. In fact, "a plus b" > is just another way of writing "a.plus(b)", so "a + b" is just a way of > writing "a.+(b)" > > Maybe it would be "useful enough" to just restrict to left-hand side:
In my opinion, this is the only reasonable way to implement operator overloads in PHP. It is easy to understand, and what can easily be understood is easy to explain, document, and to reason about. I do not understand why we're talking about commutative operations; even the inconspicuous plus operator is not commutative in PHP (https://3v4l.org/nQcL5). Those who want to implement an numerical tower (or whatever) can still implement the operations as being commutative (where appropriate) by doing manual double-dispatch. Yeah, doesn't fit with scalars, but where is the actual problem? And I wouldn't want to restrict the functionality of overloading *exiting* operators. If a library completely goes overboard with operator overloading, either only few will use it, or it might be a fantastic tool of which nobody of us could have even thought of. Now, comparison operators pose a particular issue if overloads where implemented this way, namely that the engine already swaps them; there are no greater than (or equal) OPcodes. However, this already doesn't work for uncomparable values, yielding "surprising" results (e.g. #15773). As such, it might be worth considering to have a separate PR regarding (overloading of) comparison operators. And I would consider equality operator overloading as yet a different issue, since that operation is (or at least should be) inherently commutative. What we have now, however, is not that helpful, and breaks encapsulation (https://3v4l.org/hTR2v); although without that it would be completely useless. Christoph
