On Sun, Aug 8, 2021 at 3:08 AM Deleu <deleu...@gmail.com> wrote:
> I started reading this thread with a total bias against it and as I read
> through it I can only imagine how painful and annoying it is to maintain a
> math library in PHP. Operator Overloading is truly a marvelous piece of
> functionality for that domain.
>
> However my biased still exists: it would be awful to have to understand
> what `+` is doing for every file of every library or even different objects
> in the same project.
>
May I ask why? Python does not get much criticism that I can find for its
implementation of operator overloading. Its implementation of operator
overloading is very widely used in the language and is also not seen as a
major source of "suck" for lack of a better term. Python allows virtually
all operators to be overloaded, and takes the unique approach of having an
add() method for when the object is on the left and radd() for when the
object is on the right, with precedence always going to the leftmost object.
There are many languages that provide operator overloading, and I've never
seen it described as a bad feature in any of them. I've seen criticisms of
the particular way it was implemented in a few, but not for the feature
itself. I obviously understand the possible problems that could come from
it. I work in PHP every day at work on a codebase that was originally
written 11 years ago and has been maintained, updated, and added to. We run
it on 7.4 now, and every year we have all the devs in the company spend
time on migrating to the next PHP version. In such a codebase, I'm well
aware of what kind of problems I *might* have encountered with operator
overloading.
But these don't seem to be major sources of problems in most other
languages.
Python even has multiple *default* overloads.
# prints 12
print(4 * 3)
# prints PythonPythonPython
print("Python" * 3)
So while I'm aware of the concerns, I'm unconvinced they are founded in
reality. That is, I think the concerns about maintainability and complexity
may be unfounded in real world scenarios. However it is an extremely
consistent opinion here, and I would like to understand *why* it is viewed
as bad for the language in a more concrete way if that is possible.
> It's been nearly a decade since I part ways with Math, but if I'm not
mistaken we can tackle most (all?) of the operator overloading with 2
classes: Number and NumberCollection (for lack of genetics).
> Everything in math can programmatically be represented as these two
*abstract* classes.
This would very heavily depend on how broad they were. For instance, while
complex numbers and fractions are both numbers, they would not implement
all of the same operator overrides most likely. I think this is a workable
solution, in that it would give the core feature in a way that can be
muddled through to math-domain applications. However, I won't be doing that
in my RFC. Not so much because I think it is an untennable solution for
math (although it would indeed be FAR more complex of a solution from an
RFC standpoint that directly allowing operator overrides). Instead, the
reason that I won't be doing that in my RFC is that I would no longer want
it to be accepted.
If I wrote that in my RFC just to get the overrides that benefited the work
I do, primarily around math, accepted into core, it would virtually
guarantee that actual operator overrides would never come for other types
of applications. Every future RFC on this topic would be riddled with
comments about the existing abstract classes, and how all future
implementations have to be done in a similar way. This would artificially
increase the barrier to acceptance for other domains in a way that I do not
believe improves the language, serves the users of the language, or allows
for flexible development of the language into the future.
So while I acknowledge that it may be a good middle ground (and even one
that I personally would accept for my own implementations and code), I am
unwilling to be the person that locks everyone *else* out of this language
feature by making future RFCs more constrained and difficult to pass.
I constrained this RFC to math operators not because it's the only domain
that would benefit, but because I think it's the one with the most
straightforward and understandable domain uses for everyone on this list
and represents the "minimum" version of the feature.
Jordan
