Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125609 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id DD1541A00CA for ; Wed, 18 Sep 2024 00:05:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1726618075; bh=+bBCTImhO4n/8VPJPEB7pz9CRwSGB1FeE2xgH+ZHlh0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=LpyR/cyDTL3wqiPytVs3frepwlmMNBToGZ1/rjt5JneQ+LThvJ7vUTTXGd+xE9HQ4 rputey74muaUmbIijqCZbJgfmRtCoqfo6VEavGqtR/p3hePoSdM/zWX50FHLE9wwII RpC/IA22lesrtZbsAZfD3mDi9XpMYe7IkEqe86uAnbp6JCyYzyaRTJxub8OwTKqEFp mBpwa0bxKnpnd1FLZklk/+SJWQ1x1S21aqrxovP0qopyU02Z8S7xTSQXPddZK9B07f BhBkP9IT6J+Daw+a03Wel0NYGONxuErOqxZIvOhdNRkbkrcHeH/A2w1kJCeUuRCa/m KLsmsPdLBUSyA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 17D8C1801EB for ; Wed, 18 Sep 2024 00:07:49 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 18 Sep 2024 00:07:46 +0000 (UTC) Received: by mail-pg1-f172.google.com with SMTP id 41be03b00d2f7-7d4f8a1626cso4106444a12.3 for ; Tue, 17 Sep 2024 17:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726617940; x=1727222740; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=d9SMZaVpS/1dFCkaseCO1wByEkUzHklt9jcMACIT2zA=; b=asp/VdzQ0ADLkHQL6WwIfpOpm8Xy7/sysTQneUH0DyyU5c6Fdcby8hABDlQNF/m/iK zu8zv35g28RBuBJvR5mI37U68Sy3TMKO+1NVcWWwCnB4+MQOdb+st4df1DZcYDRhOJrH CiNJMo9Mgy94kn50mnJWKRxTX6wl4WQFgTSBNavku2OQWx1YWp0wjnBhRhhiAfyuAxQS yjUw071cWKKqeBn8rC8uiH+GNKtvGfYT9aJtxJ9y6yQJhxHKzejBMMMIGh7h+DiP+ycQ LOH01Yib3bkfQSxYGZhIb4qkKGJem/MA+a6iUYbtIJlsWFASLSR+2By3WGapAv79eCcR fd5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726617940; x=1727222740; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=d9SMZaVpS/1dFCkaseCO1wByEkUzHklt9jcMACIT2zA=; b=CyKAajCI1qJ58AhHEAVew1Ffwdx3QFvXREndtZezgO2Smz8QNiVz5DA6dDuLpUOY21 39LVInoGcNRefd9sZ/Q5UBGkuZ+siO0+Kap0yWY/xoy8GEjzgVINxusiaVUBaZXVvonI RZepgEnx58suK9WWeyU7cGhAnzeTKmpCoUvh/vmugG1EtdJ0qgZ8UWOPxejAXoziZ6tV xEoqQWNTmJSz+4BSt9u+8A5bgvplwImdfS6Dh8A5Sg9r/r4VCgmaEsqUG1UG21lAHby/ Mm6F1Uz2sxqsgvYlwRzaX2vWoPrwgaboXbI1qoKaBECsJBwRLVoCfJD89BYgADpco6UC gqMw== X-Forwarded-Encrypted: i=1; AJvYcCUrdg0GJLPsvu+dJFnsdN0GJHc70qrwbS+e7P8CIR3f2D6UZIDyOuDmJpGWNtNmqHFlyARfSwgT7u4=@lists.php.net X-Gm-Message-State: AOJu0YzQ3uNEGLaB67l1CWanMztREVnkUGZL81Atap60zp0tfTZV8UyV MiXnUFPO4lDCLSDpnSkyoq/0k6TDhSrWc2AgSSQ1/4Mfqj3v7HoTzRyu5qazxd8WHFB8frW8YIE sbtXg7EaTdPFHq/4m3jZY+F/cfKD78w== X-Google-Smtp-Source: AGHT+IGuZeRxVf67dr6rtUhsxQvtO/eoLosV3uBHozKND8R7F9hihIbLgUwZUqhk192O1YMF9fjc2U8AAA7hiDbabmQ= X-Received: by 2002:a17:90b:4f91:b0:2d3:cd27:c480 with SMTP id 98e67ed59e1d1-2dbb9f7d558mr22905271a91.33.1726617939473; Tue, 17 Sep 2024 17:05:39 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <18603813-9ECB-4486-95EE-08BEDECAB88D@newclarity.net> <430bc224-c8b2-4b29-a896-b92a156babcb@gmx.net> In-Reply-To: Date: Tue, 17 Sep 2024 17:05:26 -0700 Message-ID: Subject: Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again) To: Mike Schinkel Cc: Andreas Leathley , internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000f1ff040622599046" From: jordan.ledoux@gmail.com (Jordan LeDoux) --000000000000f1ff040622599046 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 17, 2024 at 3:44=E2=80=AFPM Mike Schinkel = wrote: > On Sep 17, 2024, at 6:04 AM, Andreas Leathley wrote: > > 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 ther= e > 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. > > When you see a method call, you know 100% of the time that it calls a > method. > > Assuming operator overloading, when you see an operator used with > variables, you will no longer be able to rely on your knowledge of how th= e > operator work as it might use the built-in operator OR it might call a > method. Most of the time it will be the former, occasionally the latter. > > And since a method would only be called occasionally I would likely get > tired of searching to see if there is a method being called and just assu= me > there isn't. Not smart, but having to track down potential methods for > every operator use would just be far too tedious. > > 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. > > The more generic named the method, the more IDEs struggle with finding > methods, and operators are about as generic as you can get. > > 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 operat= or > support. Using operators implies you know you can use operators, otherwis= e > it will be a fatal error (except for comparisons). > > ANY object could have an operator overload on `=3D=3D` and/or `=3D=3D=3D`= and have > those behave differently. > > I also just checked and Symfony has many parameters type hinted as > Stringable and numerous interfaces that extend Stringable. Any object > that implements Stringable could also add operator overloads and introduc= e > subtle bugs into those functions. > > Symfony has numerous interfaces that extend Countable. Any object > that implements Countable could also add operator overloads and introduce > subtle bugs into those functions. > > Symfony has numerous interfaces that extend ArrayAccess. Any object > that implements ArrayAccess could also add operator overloads and introdu= ce > subtle bugs into those functions. > > Further =E2=80=94 if operator overloads are added =E2=80=94 there will li= kely be demand > for more "-able" type interfaces, or some other way to make objects behav= e > more like scalar types. If we have opt-in then code is safe. If we do not > have opt-in then unintended consequences are possible, if not likely. > > 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. > > We will have to agree to disagree on that then. Look at what happened whe= n > is was added to C++; people when crazy with it and it was numerous years > before the community moderated their behavior. > > Many other languages have had operator overloading for many years of even > decades - are there really huge problems in those languages? > > Depends on what you consider to be "huge" problems. Many people feel > operator overloading is a cure for an ailment where the medicine is the > worse than the disease. > > Just google "operator overloading considered harmful." But in case you > can't be bothered to google, here are just three of many opinions: > > - https://medium.com/@fmmarzoa/say-no-to-operator-overloading-7b21aa06c51= 8 > - > https://cafe.elharo.com/programming/operator-overloading-considered-harmf= ul/ > - > https://www.oreilly.com/library/view/sams-teach-yourself/0672324253/06723= 24253_ch21lev1sec4.html > > > If yes, maybe PHP can learn from some of the problems there (which I thin= k > 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? > > Besides the links above, my sources are personal experience over 30+ year= s > of programming. > > 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 ve= ry > useful, because currently using =3D=3D and =3D=3D=3D with objects is almo= st never > helpful or sufficient. > > And I support that. Just have developers or yourself opt-in to use > operators on your Money class. > > Requiring an opt-in is a safer way to go, and NOT requiring an opt-in > means we would forever have to live with any downsides that opt-in would > reign in. > > So how is requiring an opt-in a bad idea and not a reasonable compromise? > > On Sep 17, 2024, at 1:22 PM, Jordan LeDoux > wrote: > While I do not presume to speak for all voters (I don't even have voting > rights myself), my feeling from all of the conversations I have had over > almost the last 4 years is that implementing your suggestion would > virtually guarantee that the RFC is declined. > > > Well, given that few have commented on the idea yet, it seems premature t= o > make that assumption. > > Why not wait until we get more feedback rather than nix it up front? > > You are suggesting providing a new syntax (which voters tend to be > skeptical of) to create a situation where more errors occur > > (which voters tend to be skeptical of) > > > So, type hinting is all about creating errors. Yet almost everyone on th= e > list is super excited about adding more and better type hinting. > > Given that, I would argue that you are claim is, if not false, at least > far too simplistic to be a valid claim. > > to solve a problem which can be solved with existing syntax by simply typ= e > guarding your code to not allow any objects near your operators (which > voters tend to be skeptical of) > > > You mean you assume it can be solved with existing syntax. > > for which I cannot find any code examples that explain the problem it is > solving (which voters tend to skeptical of). > > > Frankly, it is difficult to come up with examples because examples are > predicating on junior developers doing dumb things that would never occur > to a senior developer because they know better. > > But I prepared one such hypothetical example using `function equals()` as > a stand-in for `operator =3D=3D` so the code will run: > > https://3v4l.org/6GTKb#v8.3.11 > > I feel certain I could come up with several others, but I unfortunately > have already exceeded my time allotment for the day. > > On Sep 17, 2024, at 1:43 PM, Jordan LeDoux > wrote: > > The problem I was trying to solve involved lots of things that cannot be > represented well by primitive types (which is presumably why they are > classes in the first place). Things like Complex Numbers, Matrices, or > Money. Money can be converted to a float of course (or an int depending o= n > implementation), but Money does not want to be added with something like > request count, which might also be an int. Or if it does, it probably wan= ts > to know exactly what the context is. There are lots of these kinds of val= ue > classes that might be representable with scalars, but would lose a lot of > their context and safety if that is done. > > On the other hand, Money would probably not want to be multiplied with > other Money values. What would Money squared mean exactly? Things like th= is > are very difficult to control for if all you provide is a way to control > casting to scaar types. > > > Given your pushback you had on even having an opt-in for operator > overload, why not instead prepare RFCs for built-in Complex Number, Matri= x, > and Money classes? > > That was what I argued three years ago yet no action was taken on it so I > get the impression that not having operator overloading for those kind of > classes is actually not that big of a deal as someone would have pushed a > class-specific RFC in that 3 years time. > > As an aside, I think it would be a LOT more valuable to have a built-in > standard that becomes always available as a starting point for everyone > doing maths rather than having a bunch of different, incompatible and > non-composable and edge-case buggy classes for these uses out on Github. > > -Mike > I really wish you would read the things that I have written. 1. No objects would be able to overload the `=3D=3D=3D` operator, because t= hat operator was not included in the RFC intentionally. 2. The current semantics of the `=3D=3D` with objects are possibly used by some, but in practice from what I have seen and researched, are mostly so useless that they aren't used. But, even so, the comparison operators in the original RFC actually DO fall back to the existing behavior if no overload is present. 3. I don't know how else to explain this to you, but the existence of an operator in your code does NOT mean you would now need to do more work if you do not want to take advantage of operator overloads, even without an opt-in. Currently using objects with an operator results in a fatal error. Since you presumably have written code that can run in the last 30+ years of your experience, you have somehow avoided this. I presume you have avoided this situation by paying attention to the types of your variables. You may continue to do the same thing you MUST do now, and you will never encounter an operator overload. Ever. 4. None of the Symfony code that allows Stringable or Countable will suddenly produce new bugs without intentionally adding operators. I know this because the code currently does not produce errors, and currently any object that is Stringable and/or Countable will produce errors when it encounters any of the operators specified in the original RFC (excluding comparisons, which I have mentioned). ArrayAccess.... perhaps? Arrays can use `+` to union, and I'm not sure off the top of my head if ArrayAccess also does this. But that's an internal implementation that could be forced to remain the same fairly trivially if so. 5. I addressed this multiple times in my original RFC and the discussion surrounding it, but C++ is the most useless analogue anyone could choose for what I am proposing, and also just HAPPENS to be the language with the most negative impact from its operator overload implementation. I noticed this in my research prior to the RFC (which is the point of such research), and I made design choices SPECIFICALLY to avoid that and then communicated that to everyone via multiple channels including this mailing list and the original RFC. The vast majority of trouble that C++ operator overloads cause are related to overloads with pointers. Pointers do not exist in PHP, and their closest analogue (by-ref) are specifically not possible with overloads to prevent that very problem. 6. The articles you linked to about the evils of operator overload seem to be essentially making the point "people will misuse operator overloading". Sure. In fact the RFC I wrote had a section dedicated to that. People will misuse ANYTHING. I don't see that on its own as a legitimate reason to avoid a feature that has legitimate uses. I spent a lot of time researching this aspect of it in different developer communities, and my conclusion eventually was "most developer communities for languages that have operator overloads do not appear to see them as a particularly troublesome source of quirks, bugs, and confusion". I don't think that the Python or C# communities for instance would support removing the feature, even if there were a way to magically fix the BC issues it would cause. It is seen as a useful but niche feature, which is exactly what it is. 7. Your opt-in concept is a bad idea because it creates multiple switchable modes for the VM to run in, which is something that I think most developers would find MUCH more mentally taxing than simply adjusting to the new feature. 8. It is not merely an "assumption" that existing syntax can solve the issue you are trying to solve. The following operators ALWAYS result in a fatal error when used with an object that doesn't have an overload: `+`, `-`, `*`, `/`, `%`, `**`, `^`, `&`, `|`, `<<`, `>>`, `~`. These operators are currently used in code that does not produce errors. Ergo, there is an existing syntax that prevents their use with objects. Ergo, there is an existing syntax that solves the issue. In fact there are multiple. 9. I have not prepared RFCs for bundled Complex Number, Matrix, etc. types because those are just the use cases that brought me to this feature, not the only ones I have encountered, and I don't think that special-casing an internal class for every single one is a sustainable solution. How long before we end up with a Currency class also? Or a Length, Area, and Volume class that all understand how to multiply and divide into each other? What about other measurement units getting their own? I think that same thought process would also work against the idea of a Complex Number of Matrix class, and frankly, something like a Complex Number class is HIGHLY specific and would be virtually unused. I might have a use for it, but including it in the language is fairly dubious. Almost everything you have said are things that I have talked about or been asked about for years. That is why I have been fairly dismissive about them so far, not because I disagree. I am well familiar with these discussions, and I was hoping to get new feedback and thoughts through this thread. To hear specifics. The specifics I hear from you is something along the lines of "as long as you give me a way to force all my code, even code other developers wrote, to ignore this feature, I am fine with it". That's not really a helpful position at all, even if it IS a valid one. Jordan --000000000000f1ff040622599046 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Sep 17, 2024 at 3:44=E2=80=AF= PM Mike Schinkel <mike@newclarity= .net> wrote:
On Sep 17, 2024, at 6:04 AM, Andreas Leathley <a.leathley@gmx.net> wrote:
=20 =20 =20
On 17.09.24 11:14, Mike Schinkel wrote:
How woul= d a developer know if they are using an object that has operators, unless t= hey study all the source code or at least the docs (assuming there are good= docs, which there probably are not?)

How is that di= fferent 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.

When you see a method call, you kno= w 100% of the time that it calls a method.

Assumin= g operator overloading, when you see an operator used with variables, you w= ill no longer be able to rely on your knowledge of how the operator work as= it might use the built-in operator OR it might call a method. Most of the = time it will be the former, occasionally the latter. =C2=A0

<= /div>
And since a method would only be called occasionally I would like= ly get tired of searching to see if there is a method being called and just= assume there isn't. Not smart, but having to track down potential meth= ods for every operator use would just be far too tedious.

Also, getting to the implementation of operators w= ould likely be just as easy as looking up methods nowadays, because IDEs would support that kind of lookup.

The= more generic named the method, the more IDEs struggle with finding methods= , and operators are about as generic as you can get.

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).

ANY object could have an operator overload on `=3D=3D` a= nd/or `=3D=3D=3D` and have those behave differently.

I = also just checked and Symfony has many parameters type hinted as Stringable= and numerous interfaces that extend=C2=A0Stringable.=C2=A0 Any object that= =C2=A0implements=C2=A0Stringable could also add operator overloads and intr= oduce subtle bugs into those functions.

Symfo= ny has numerous interfaces that extend Countable.=C2=A0 Any object that=C2= =A0implements=C2=A0Countable could also add operator overloads and introduc= e subtle bugs into those functions.

Symfony h= as numerous interfaces that extend ArrayAccess.=C2=A0 Any object that=C2=A0= implements=C2=A0ArrayAccess=C2=A0could also add operator overloads and intr= oduce subtle bugs into those functions.

Further =E2=80=94 if operator overloads are added =E2=80=94 there will li= kely be demand for more "-able" type interfaces, or some other wa= y to make objects behave more like scalar types. If we have opt-in then cod= e is safe. If we do not have opt-in then unintended consequences are possib= le, if not likely.

From your ar= guments 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.

We will have to agree= to disagree on that then. Look at what happened when is was added to C++; = people when crazy with it and it was numerous years before the community mo= derated their behavior.

Many oth= er languages have had operator overloading for many years of even decades - are there really huge problems in those languages?

Depends on w= hat you consider to be "huge" problems.=C2=A0 Many people feel op= erator overloading is a cure for an ailment where the medicine is the worse= than the disease. =C2=A0

Just google "operat= or overloading considered harmful." =C2=A0But in case you can't be= bothered to google, here are just three of many opinions:


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?

Besides the links above, my sources are person= al experience over 30+ years of programming.

Personally I would love my Money class to finally have operators instead of the current "plus", "minus", "mul= tipliedBy" (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 objects is almost n= ever helpful or sufficient.

And I support that.=C2=A0 Just have developers or yourself opt= -in to use operators on your Money class. =C2=A0

R= equiring an opt-in is a safer way to go, and NOT requiring an opt-in means = we would forever have to live with any downsides that opt-in would reign in= .=C2=A0

So how is requiring an opt-in a bad idea a= nd not a reasonable compromise? =C2=A0

On Sep 17, 2024, at 1:2= 2 PM, Jordan LeDoux <jordan.ledoux@gmail.com> wrote:
While I do not presum= e to speak for all voters (I don't even have voting rights myself), my = feeling from all of the conversations I=C2=A0have had over almost the last = 4 years is that implementing your suggestion would virtually guarantee that= the RFC is declined.

Well, given that few have comment= ed on the idea yet, it seems premature to make that assumption.=C2=A0
Why not wait until we get more feedback rather than nix it up front?
<= br>
You are suggesting providing a new syntax (whi= ch voters tend to be skeptical of) to create a situation where more errors = occur
(which voters tend to be sk= eptical of)

So, type hinting is all about creating erro= rs.=C2=A0 Yet almost everyone on the list is super excited about adding mor= e and better type=C2=A0hinting.=C2=A0=C2=A0

Given that, I would argu= e that you are claim is, if not false, at least far too simplistic to be a = valid claim.

to solve a problem which can = be solved with existing syntax by simply type guarding your code to not all= ow any objects near your=C2=A0operators (which voters tend to be skeptical = of)

You mean you assume it can be solved with existing = syntax.

for which I cannot find any code e= xamples that explain the problem it is solving (which voters tend to skepti= cal of).

Frankly, it is difficult to come up with examp= les because examples are predicating on junior developers doing dumb things= that would never occur to a=C2=A0senior developer because they know better= .=C2=A0=C2=A0

But I prepared one such hypothetical example using `fu= nction equals()` as a stand-in for `operator =3D=3D` so the code will run:= =C2=A0

= https://3v4l.org/6GTKb#v8.3.11

I feel certain I could come up wi= th several others, but I unfortunately have already exceeded my time allotm= ent for the day.

= On Sep 17, 2024, at 1:43 PM, Jordan LeDoux <jordan.ledoux@gmail.com> wrote:

The problem I was trying to solve involved l= ots of things that cannot be represented well by primitive types (which is = presumably why they are classes in the first place). Things like Complex Nu= mbers, Matrices, or Money. Money can be converted to a float of course (or = an int depending on implementation), but Money does not want to be added wi= th something like request count, which might also be an int. Or if it does,= it probably wants to know exactly what the context is. There are lots of t= hese kinds of value classes that might be representable with scalars, but w= ould lose a lot of their context and safety if that is done.

=
On the other hand, Money would probably not want to be multiplie= d with other Money values. What would Money squared mean exactly? Things li= ke this are very difficult to control for if all you provide is a way to co= ntrol casting to scaar types.

<= /div>
Given your pushback you had on even having an opt-in for operator= overload, why not instead prepare RFCs for built-in Complex Number, Matrix= , and Money classes? =C2=A0

That was what I argued= three years ago yet no action was taken on it so I get the impression that= not having operator overloading for those kind of classes is actually not = that big of a deal as someone would have pushed a class-specific RFC in tha= t 3 years time.

As an aside, I think it would be a= LOT more valuable to have a built-in standard that becomes always availabl= e as a starting point for everyone doing maths rather than having a bunch o= f different, incompatible and non-composable and edge-case buggy classes fo= r these uses out on Github.

-Mike

I really wish you would read the th= ings that I have written.

1. No objects would be a= ble to overload the `=3D=3D=3D` operator, because that operator was not inc= luded in the RFC intentionally.

2. The current sem= antics of the `=3D=3D` with objects are possibly used by some, but in pract= ice from what I have seen and researched, are mostly so useless that they a= ren't used. But, even so, the comparison operators in the original RFC = actually DO fall back to the existing behavior if no overload is present.

3. I don't know how else to explain this to you= , but the existence of an operator in your code does NOT mean you would now= need to do more work if you do not want to take advantage of operator over= loads, even without an opt-in. Currently using objects with an operator res= ults in a fatal error. Since you presumably have written code that can run = in the last 30+ years of your experience, you have somehow avoided this. I = presume you have avoided this situation by paying attention to the types of= your variables. You may continue to do the same thing you MUST do now, and= you will never encounter an operator overload. Ever.

<= div>4. None of the Symfony code that allows Stringable or Countable will su= ddenly produce new bugs without intentionally adding operators. I know this= because the code currently does not produce errors, and currently any obje= ct that is Stringable and/or Countable will produce errors when it encounte= rs any of the operators specified in the original RFC (excluding comparison= s, which I have mentioned). ArrayAccess.... perhaps? Arrays can use `+` to = union, and I'm not sure off the top of my head if ArrayAccess also does= this. But that's an internal implementation that could be forced to re= main the same fairly trivially if so.

5. I address= ed this multiple times in my original RFC and the discussion surrounding it= , but C++ is the most useless analogue anyone could choose for what I am pr= oposing, and also just HAPPENS to be the language with the most negative im= pact from its operator overload implementation. I noticed this in my resear= ch prior to the RFC (which is the point of such research), and I made desig= n choices SPECIFICALLY to avoid that and then communicated that to everyone= via multiple channels including this mailing list and the original RFC. Th= e vast majority of trouble that C++ operator overloads cause are related to= overloads with pointers. Pointers do not exist in PHP, and their closest a= nalogue (by-ref) are specifically not possible with overloads to prevent th= at very problem.

6. The articles you linked to abo= ut the evils of operator overload seem to be essentially making the point &= quot;people will misuse operator overloading". Sure. In fact the RFC I= wrote had a section dedicated to that. People will misuse ANYTHING. I don&= #39;t see that on its own as a legitimate reason to avoid a feature that ha= s legitimate uses. I spent a lot of time researching this aspect of it in d= ifferent developer communities, and my conclusion eventually was "most= developer communities for languages that have operator overloads do not ap= pear to see them as a particularly troublesome source of quirks, bugs, and = confusion". I don't think that the Python or C# communities for in= stance would support removing the feature, even if there were a way to magi= cally fix the BC issues it would cause. It is seen as a useful but niche fe= ature, which is exactly what it is.

7. Your opt-in= concept is a bad idea because it creates multiple switchable modes for the= VM to run in, which is something that I think most developers would find M= UCH more mentally taxing than simply adjusting to the new feature.

8. It is not merely an "assumption" that existin= g syntax can solve the issue you are trying to solve. The following operato= rs ALWAYS result in a fatal error when used with an object that doesn't= have an overload: `+`, `-`, `*`, `/`, `%`, `**`, `^`, `&`, `|`, `<&= lt;`, `>>`, `~`. These operators are currently used in code that does= not produce errors. Ergo, there is an existing syntax that prevents their = use with objects. Ergo, there is an existing syntax that solves the issue. = In fact there are multiple.

9. I have not prepared= RFCs for bundled Complex Number, Matrix, etc. types because those are just= the use cases that brought me to this feature, not the only ones I have en= countered, and I don't think that special-casing an internal class for = every single one is a sustainable solution. How long before we end up with = a Currency class also? Or a Length, Area, and Volume class that all underst= and how to multiply and divide into each other? What about other measuremen= t units getting their own? I think that same thought process would also wor= k against the idea of a Complex Number of Matrix class, and frankly, someth= ing like a Complex Number class is HIGHLY specific and would be virtually u= nused. I might have a use for it, but including it in the language is fairl= y dubious.

Almost everything you have said are thi= ngs that I have talked about or been asked about for years. That is why I h= ave been fairly dismissive about them so far, not because I disagree. I am = well familiar with these discussions, and I was hoping to get new feedback = and thoughts through this thread. To hear specifics.

The specifics I hear from you is something along the lines of "as l= ong as you give me a way to force all my code, even code other developers w= rote, to ignore this feature, I am fine with it". That's not reall= y a helpful position at all, even if it IS a valid one.

Jordan
--000000000000f1ff040622599046--