On Wed, 18 Sep 2024, at 15:19, Christoph M. Becker wrote:
>> 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).

There are really three different things we shouldn't confuse:

1) Commutativity of the operation, as in $a + $b and $b + $a having the same 
result. As you say, this is a non-goal; we already have examples of 
non-commutative operators in PHP, and there are plenty more that have been 
given.

2) Commutativity of the *resolution*. This is slightly subtler: if $a and $b 
both have implementations of the operator, should $a + $b and $b + $a call the 
same implementation? We can say "no", but it may be surprising to some users 
that if $b is a sub-class of $a, its version of + isn't used by preference.

3) Resolution when *only one side has an implementation*. For instance, how do 
you define an overload for 1 / $object? Or for (new DateTime) + (new 
MySpecialDateOffset)? It's possible to work around this if the custom class has 
to be on the left, but probably not very intuitive.

It's also worth considering that the *resolution* of PHP's operators aren't 
currently determined by their left-hand side, e.g. int + float and float + int 
both return a float, which certainly feels like "preferring the float 
implementation regardless of order", even if PHP doesn't technically implement 
it that way.

Regards,
-- 
Rowan Tommins
[IMSoP]

Reply via email to