Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125582
Content-Type: multipart/alternative;
 boundary="------------S0bkrYaaZWR9b69hv0Vjs72d"
Message-ID: <bd32a9a0-fb2d-4fb3-9c88-ee7d5f8f6ab2@gmx.net>
Date: Tue, 17 Sep 2024 13:21:35 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads
 (again)
Content-Language: en-US
To: internals@lists.php.net
References: <CAMrTa2E2m00gOoGy5FbvkrLwM1AUP3ZmJXHkxh_R2qEszQ=NWA@mail.gmail.com>
In-Reply-To: <CAMrTa2E2m00gOoGy5FbvkrLwM1AUP3ZmJXHkxh_R2qEszQ=NWA@mail.gmail.com>
UI-OutboundReport: notjunk:1;M01:P0:2ZuHUxXrr6g=;mE+2Vy2B9ZbulvhGHO5aX9NuXtX
 MBKk84bRj/BO4a32Of9KdJVqkpPr3aQBlFsu1tdaLzKvTF6XoNj7OAxR3QodXx3O9z3hilckw
 p1SCQgoSybsfU67rNiXZ/KlFn3O5jxxpOfylheN/u3iWZQGZtuh82z4LHFfPU3CnIf9O7qesZ
 6U3iZLZ8dHbcwHjmdJeAdVajeptQgzIQUjRgADvD7buTnvNpIlsvT7y2CkuawaO1DYNmuCkvC
 mFFvHPlQzl5ub+KnlB4GLYNTNjFby2LjfAH5ZkSBhsb3xMvmj3Z5BJF4efcRKkKSInpYsBVYI
 GrsWmEV6rpfQSZPsezkrmItycrgCB90vSyH1U0O9kCKXYhayicAStU0zFSdtPqhzi4woUvtFv
 5OQ8KuF4Z6n3ZzbjIaKit1YpJVee8w4nyJ1OvqT8TEEIq5Qac2R43wPAn5m/rntTfeEuefSYE
 n1JmdJwp2rqaxFnH4A3kJIqKbDD+9HM9xWqIpyhW5SZvF85sIgJrwjmyk+aFE/mfRdC7p8CQw
 lRrH3fSchstP1jCxmAhOGknZFm21NG6FXaz6H2RZCUjf6yubwU4WqnLQS9ETCFK5Hhl6TfCp8
 /41vuPKhr1VVZqWwI1D3dnf9wSO2E2l0tgKQblzpbDcAaxL70UoGpkdj2MngeIVkA18mbmtpy
 hS+UQhDbw8308CesKZYt1i413BDTsFFzGlyB/KUvr1siSsbbK4oN8Sx5iH0jPx7B3LqP6QQeY
 jeYSPyrjnNi1gZgMh6LHT8mt/su3QB9cRmOTTRmRsU5z4w+3GZNt1+eyZh6ZSoCQNf0Y2pmiL
 JP3PkJBU+4hKiFFkVY9XcFsQ==
From: a.leathley@gmx.net (Andreas Leathley)

This is a multi-part message in MIME format.
--------------S0bkrYaaZWR9b69hv0Vjs72d
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 14.09.24 23:48, Jordan LeDoux wrote:
>
> 1. Should the next version of this RFC use the `operator` keyword, or
> should that approach be abandoned for something more familiar? Why do
> you feel that way?
>
> 2. Should the capability to overload comparison operators be provided
> in the same RFC, or would it be better to separate that into its own
> RFC? Why do you feel that way?
>
> 3. Do you feel there were any glaring design weaknesses in the
> previous RFC that should be addressed before it is re-proposed?
>
> 4. Do you feel that there is ANY design, version, or implementation of
> operator overloads possible that you would support and be in favor of,
> regardless of whether it matches the approach taken previously? If so,
> can you describe any of the core ideas you feel are most important?
>
Hello Jordan,

Happy you are following up on operator overloads, as I was sad to see
the vote fail last time.

I think the RFC might benefit from focusing on the comparison operators
and the basic arithmetic operators this time, so =3D=3D, <=3D>, +, -, *, /
(and maybe % and **). I would especially leave out the bitwise operators
(for a possible future RFC), as those to me seem extra niche and not
very self-explanatory in terms of good use cases/examples. =3D=3D, <=3D>, =
+,
-, * and / would deliver almost all the benefits to operator overloading
I can currently think of.

Giving more concrete examples in the RFC of places in the current PHP
ecosystem where these operators would simplify code might be helpful -
the last RFC had mainly a generic list of use cases, but seeing actual
code would help to make it salient how some code can be a lot more
readable, especially if you now know about even more use cases than 3
years ago.

Otherwise I am hoping that more opponents of operator overloads will
chime in and give some constructive feedback.

--------------S0bkrYaaZWR9b69hv0Vjs72d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 14.09.24 23:48, Jordan LeDoux wrote:</div>
    <blockquote type="cite"
cite="mid:CAMrTa2E2m00gOoGy5FbvkrLwM1AUP3ZmJXHkxh_R2qEszQ=NWA@mail.gmail.com">
      <div dir="ltr"><br>
        <p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"
          role="presentation"><span
style="font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">1. Should the next version of this RFC use the `operator` keyword, or should that approach be abandoned for something more familiar? Why do you feel that way?</span></p>
        <p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"
          role="presentation"><span
style="font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">2. Should the capability to overload comparison operators be provided in the same RFC, or would it be better to separate that into its own RFC? Why do you feel that way?</span></p>
        <p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"
          role="presentation"><span
style="font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">3. Do you feel there were any glaring design weaknesses in the previous RFC that should be addressed before it is re-proposed?</span></p>
        <p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"
          role="presentation"><span
style="font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">4. Do you feel that there is ANY design, version, or implementation of operator overloads possible that you would support and be in favor of, regardless of whether it matches the approach taken previously? If so, can you describe any of the core ideas you feel are most important?
</span></p>
      </div>
    </blockquote>
    <p>Hello Jordan,</p>
    <p>Happy you are following up on operator overloads, as I was sad to
      see the vote fail last time.<br>
    </p>
    <p>I think the RFC might benefit from focusing on the comparison
      operators and the basic arithmetic operators this time, so ==,
      &lt;=&gt;, +, -, *, / (and maybe % and **). I would especially
      leave out the bitwise operators (for a possible future RFC), as
      those to me seem extra niche and not very self-explanatory in
      terms of good use cases/examples. ==, &lt;=&gt;, +, -, * and /
      would deliver almost all the benefits to operator overloading I
      can currently think of.<br>
    </p>
    <p>Giving more concrete examples in the RFC of places in the current
      PHP ecosystem where these operators would simplify code might be
      helpful - the last RFC had mainly a generic list of use cases, but
      seeing actual code would help to make it salient how some code can
      be a lot more readable, especially if you now know about even more
      use cases than 3 years ago.<br>
    </p>
    <p>Otherwise I am hoping that more opponents of operator overloads
      will chime in and give some constructive feedback.<br>
    </p>
  </body>
</html>

--------------S0bkrYaaZWR9b69hv0Vjs72d--