Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125605
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------hlfCB5s907kVvc1d3FV0FpiH"
Message-ID: <12de3d03-3426-44f8-a83f-d686d2034912@rwec.co.uk>
Date: Tue, 17 Sep 2024 23:13:13 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads
 (again)
To: internals@lists.php.net
References: <CAMrTa2E2m00gOoGy5FbvkrLwM1AUP3ZmJXHkxh_R2qEszQ=NWA@mail.gmail.com>
 <2551c06a-ec1f-4870-a590-aeb5752fc944@rwec.co.uk>
 <CAMrTa2FLJwjwy9uGpRJJJFMUD1vs=vqzv8x2VxMsYeBqMN4m9Q@mail.gmail.com>
 <0f0444eb-8fc5-4c56-8528-5aa528988e73@rwec.co.uk>
 <e4c478c5-03b5-4cfd-95c4-6161d88557fa@app.fastmail.com>
Content-Language: en-GB
In-Reply-To: <e4c478c5-03b5-4cfd-95c4-6161d88557fa@app.fastmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------hlfCB5s907kVvc1d3FV0FpiH
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 17/09/2024 21:37, Rob Landers wrote:
> I would prefer to see something simple, and easy to reason about. We 
> can abuse some mathematical properties to result in something quite 
> simple:
>
>  1. If both are scalar, use existing logic.
>  2. If one is scalar and the other is not, use existing logic.
>  3. If one is scalar and the other overrides the operation, rearrange
>     the operation per its communitive rules so the object is on the
>     left. $scalar + $obj == $obj + $scalar; $scalar - $obj == -$obj +
>     $scalar, -($obj - $scalar). It is generally accepted (IIRC) that
>     when scalars are involved, we don’t need to be concerned with
>     non-abelion groups.
>  4. If both are objects, use the one on the left.
>

Step 3 requires operators to be overloaded in groups: the rearrangement 
of the binary "-" operator requires definitions of both the unary "-" 
operator and the binary "+" operator; and definitions that meet the 
appropriate mathematical rules.

IMO, that's a lot more complicated than calling the "+" overload with an 
OperandPosition::RightSide flag; or Python's approach of separate "add" 
and "reflected add" magic methods.


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:

1. If the left operand is an object which implements the specified 
operator, call that implementation with the right operand as argument
2. Else, proceed as current PHP.


This is where gathering a good catalogue of use cases would come in 
handy: which of them would be impossible, or annoyingly difficult, with 
a more restrictive resolution method?

Regards,

-- 
Rowan Tommins
[IMSoP]

--------------hlfCB5s907kVvc1d3FV0FpiH
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 17/09/2024 21:37, Rob Landers wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:e4c478c5-03b5-4cfd-95c4-6161d88557fa@app.fastmail.com">
      <div>I would prefer to see something simple, and easy to reason
        about. We can abuse some mathematical properties to result in
        something quite simple:<br>
      </div>
      <div><br>
      </div>
      <ol>
        <li>If both are scalar, use existing logic. <br>
        </li>
        <li>If one is scalar and the other is not, use existing logic. <br>
        </li>
        <li>If one is scalar and the other overrides the operation,
          rearrange the operation per its communitive rules so the
          object is on the left. $scalar + $obj == $obj + $scalar;
          $scalar - $obj == -$obj + $scalar, -($obj - $scalar). It is
          generally accepted (IIRC) that when scalars are involved, we
          don’t need to be concerned with non-abelion groups.<br>
        </li>
        <li>If both are objects, use the one on the left.</li>
      </ol>
    </blockquote>
    <p><br>
    </p>
    <p>Step 3 requires operators to be overloaded in groups: the
      rearrangement of the binary "-" operator requires definitions of
      both the unary "-" operator and the binary "+" operator; and
      definitions that meet the appropriate mathematical rules. <br>
    </p>
    <p>IMO, that's a lot more complicated than calling the "+" overload
      with an OperandPosition::RightSide flag; or Python's approach of
      separate "add" and "reflected add" magic methods.</p>
    <p><br>
    </p>
    <p>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)"<br>
    </p>
    <p><br>
    </p>
    <p>Maybe it would be "useful enough" to just restrict to left-hand
      side:</p>
    <p>1. If the left operand is an object which implements the
      specified operator, call that implementation with the right
      operand as argument<br>
      2. Else, proceed as current PHP.</p>
    <p><br>
    </p>
    <p>This is where gathering a good catalogue of use cases would come
      in handy: which of them would be impossible, or annoyingly
      difficult, with a more restrictive resolution method?<br>
    </p>
    <p>Regards,<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------hlfCB5s907kVvc1d3FV0FpiH--