Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125581
Content-Type: multipart/alternative;
 boundary="------------jjzd5yHO8UP4fdZ9Q83Mb266"
Message-ID: <430bc224-c8b2-4b29-a896-b92a156babcb@gmx.net>
Date: Tue, 17 Sep 2024 12:04:36 +0200
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>
 <F2492D64-797D-4195-A996-AF1F7C758674@gmail.com>
 <18603813-9ECB-4486-95EE-08BEDECAB88D@newclarity.net>
 <CAMrTa2HzaSssZYJ6PrWkKDfsGVWyTq0_aB5xGKTS=Nb8GHiOug@mail.gmail.com>
 <F6B400AE-A092-43F2-BB1A-B3A5EB0EBD4B@newclarity.net>
Content-Language: en-US
In-Reply-To: <F6B400AE-A092-43F2-BB1A-B3A5EB0EBD4B@newclarity.net>
UI-OutboundReport: notjunk:1;M01:P0:Irf7LTTy2VE=;4tg/5KF6JG4gpvfA6ZE3Ke6ec5a
 neBgd8yieQNDgtv9A2gxLuFjSkCoKKsk/KAYJ2Vr180esv7YvXMLTtKQ8H/hj2xVejJjKPMjU
 vzLWrM7OJd5ftM8updZTJL9rUvczI0mXiEX6co/GkeXvgORdqmirTobKTft+MluhPtF7YXQ4I
 C4x9S6mV9Qyz/2S964X3dux3qH6EYbyEmcDF85oN2VG6LhUs8NkSMOlEPleu5l5sM4lBsvJzZ
 X669HXJEeQkFkNkLDA4hbBmEOt6yBqksuY1N1737M7KHzSICSfBUFTXHKLRYgOoit/7jPk6J5
 2sb9D33GKVLAIU0GQkJgBolcrWpPFwmYGYzQABOPFBT225HYFa/BY8ZdldaqHexFfnpLfTZVo
 4EZcaodnfeWtCv1A0R2KZgtIXDJG+O8Qua6XLZCxl4S96AWwg95+yn3vEVMymlrKWkBCD7qNZ
 WELV0Whv0QukQEGca6snEXkHJzPsPcB3tLGo59W0+NKFMPluW82k3unTiiamHgS73MBTh0o1+
 gvoUYA3Pxkan54Vk4fpZksOHpCy5gZ5pVIcAnEUhuSER90k7jyqmCru9MAG3iH7qEcP/bHaO9
 MrcXty6OtW08WrGNUCDbPaMYd7cLI1ykobv+iXbGIu76fcsHbN5OFcuyRHFtvnOOjUfgswfKM
 CnvX+A+VsximSbcbe6tlgssErq4ETuUBF2vowsHsa3Qgtq3zF64gPut6tzql4/VbbmYkll05q
 LCa9zFGnRIPKJOqLX1egTb3pxQZz8xWqm6kKTXMFwmtTCdNXhJo9G3uiuVWAEFFthhXSf682r
 A7OJjkDnMoxR3iNOFB/co3Dw==
From: a.leathley@gmx.net (Andreas Leathley)

This is a multi-part message in MIME format.
--------------jjzd5yHO8UP4fdZ9Q83Mb266
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 17.09.24 11:14, Mike Schinkel wrote:
> How would a developer know if they are using an object that has
> operators, unless they study all the source code or at least the docs
> (assuming there are good docs, which there probably are not?)

How is that different from using a method on an object? Operators are
roughly speaking a different syntax for methods, and if you use an
object method, you have to know about it or look up what it does.

Also, getting to the implementation of operators would likely be just as
easy as looking up methods nowadays, because IDEs would support that
kind of lookup.

> Situation where there is free-reign userland operator overloading:  Juni=
or developer Joe is using Symfony and learns about this great new operator=
 overload feature so decides to implement all the operators for all his ob=
jects, and now he wants to start passing his objects to Symphony code. Joe=
 decides to be clever and implement "/" to concatenate paths strings toget=
her but doesn't type his properties, and he ends up passing them to a Symf=
ony function that uses `/` for division, and his program crashes with very=
 cryptic error messages.  He reports them to the Symfony developers, and i=
t wastes a bunch of time for everyone until they finally figure out why it=
 failed, because nobody every considered a developer would do such a thing=
.

Most framework and library code is by now type-hinted - I would have
understood this argument when operator overloading would be implemented
into PHP 5.x, where many classes and functions got values and had no
enforced types, so they might have expected an int, yet an object with
operator overloading might work but in weird ways, because there were no
type hints for int. I cannot see this situation now at all - if a
Symfony component wants an int, you cannot pass in an object. If a
Symfony component wants a Request object, it will not use operators that
it does not expect to be there, even if you would extend the class and
add operator support. Using operators implies you know you can use
operators, otherwise it will be a fatal error (except for comparisons).

 From your arguments it also seems you are afraid everybody will use
operator overloading excessively and unnecessarily. This seems very
unlikely to me - it is not that useful a feature, except for certain
situations. Many other languages have had operator overloading for many
years of even decades - are there really huge problems in those
languages? If yes, maybe PHP can learn from some of the problems there
(which I think the original RFC tried to carefully consider), but as far
as I know the usage of operator overloading is niche in languages which
support it, depending on use case - some people like it, some don't, but
they do not seem to be a big problem for these languages or their code
in general. Maybe you have some sources on actual problems in other
languages?

Personally I would love my Money class to finally have operators instead
of the current "plus", "minus", "multipliedBy" (and so on) methods which
are far less readable. I would only use operator overloading on a few
specific classes, but for those the readability improvement would be
huge. Also, being able to override comparison operators for objects
would be very useful, because currently using =3D=3D and =3D=3D=3D with ob=
jects is
almost never helpful or sufficient.

--------------jjzd5yHO8UP4fdZ9Q83Mb266
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 17.09.24 11:14, Mike Schinkel wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:F6B400AE-A092-43F2-BB1A-B3A5EB0EBD4B@newclarity.net"><span
      style="white-space: pre-wrap">How would a developer know if they are using an object that has operators, unless they study all the source code or at least the docs (assuming there are good docs, which there probably are not?) </span></blockquote>
    <p>How is that different from using a method on an object? Operators
      are roughly speaking a different syntax for methods, and if you
      use an object method, you have to know about it or look up what it
      does.</p>
    <p>Also, getting to the implementation of operators would likely be
      just as easy as looking up methods nowadays, because IDEs would
      support that kind of lookup.<br>
    </p>
    <blockquote type="cite"
      cite="mid:F6B400AE-A092-43F2-BB1A-B3A5EB0EBD4B@newclarity.net"><span
      style="white-space: pre-wrap">
</span>
      <pre class="moz-quote-pre" wrap="">Situation where there is free-reign userland operator overloading:  Junior developer Joe is using Symfony and learns about this great new operator overload feature so decides to implement all the operators for all his objects, and now he wants to start passing his objects to Symphony code. Joe decides to be clever and implement "/" to concatenate paths strings together but doesn't type his properties, and he ends up passing them to a Symfony function that uses `/` for division, and his program crashes with very cryptic error messages.  He reports them to the Symfony developers, and it wastes a bunch of time for everyone until they finally figure out why it failed, because nobody every considered a developer would do such a thing.</pre>
    </blockquote>
    <p>Most framework and library code is by now type-hinted - I would
      have understood this argument when operator overloading would be
      implemented into PHP 5.x, where many classes and functions got
      values and had no enforced types, so they might have expected an
      int, yet an object with operator overloading might work but in
      weird ways, because there were no type hints for int. I cannot see
      this situation now at all - if a Symfony component wants an int,
      you cannot pass in an object. If a Symfony component wants a
      Request object, it will not use operators that it does not expect
      to be there, even if you would extend the class and add operator
      support. Using operators implies you know you can use operators,
      otherwise it will be a fatal error (except for comparisons).</p>
    <p>From your arguments it also seems you are afraid everybody will
      use operator overloading excessively and unnecessarily. This seems
      very unlikely to me - it is not that useful a feature, except for
      certain situations. Many other languages have had operator
      overloading for many years of even decades - are there really huge
      problems in those languages? If yes, maybe PHP can learn from some
      of the problems there (which I think the original RFC tried to
      carefully consider), but as far as I know the usage of operator
      overloading is niche in languages which support it, depending on
      use case - some people like it, some don't, but they do not seem
      to be a big problem for these languages or their code in general.
      Maybe you have some sources on actual problems in other languages?<br>
    </p>
    <p>Personally I would love my Money class to finally have operators
      instead of the current "plus", "minus", "multipliedBy" (and so on)
      methods which are far less readable. I would only use operator
      overloading on a few specific classes, but for those the
      readability improvement would be huge. Also, being able to
      override comparison operators for objects would be very useful,
      because currently using == and === with objects is almost never
      helpful or sufficient.<br>
    </p>
  </body>
</html>

--------------jjzd5yHO8UP4fdZ9Q83Mb266--