Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115664
MIME-Version: 1.0
References: <CAMrTa2EO-5nyoCYkHhMVxQ4nucRoHJj0=M=W22kUaW0jpHkHLg@mail.gmail.com>
 <f01eed58-6ccb-91a9-16d0-0f0c4e97d98a@gmail.com> <CAMrTa2E-pV+xP+3NJ=zd0S7N2agVRGiALaaJCBUaM=UwETEArw@mail.gmail.com>
 <94696d46-c4e6-406a-b859-89144bff31bf@www.fastmail.com> <D4BCCF3A-2DA1-4091-917D-7EBDB4A1AB5C@newclarity.net>
 <CAMrTa2GLQuVAKL089ykDJnBfVw=MNP-3qiTzHFpjQ8WTmUK+Lw@mail.gmail.com>
In-Reply-To: <CAMrTa2GLQuVAKL089ykDJnBfVw=MNP-3qiTzHFpjQ8WTmUK+Lw@mail.gmail.com>
Date: Sun, 8 Aug 2021 12:07:58 +0200
Message-ID: <CADK1yXKSmeBd8=AVriDD9GSCPPE=-Rztzt_btWzFEAzXLZzY-w@mail.gmail.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004c9bb505c9097243"
Subject: Re: [PHP-DEV] Revisiting Userland Operator Overloads
From: deleugyn@gmail.com (Deleu)

--0000000000004c9bb505c9097243
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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.



> > Ruby has operator overloading, and one of the distasteful aspects I fou=
nd
> > regarding in programming in Ruby was that everybody's Ruby code you
> looked
> > at felt like I was written in a slightly different language. I would ha=
te
> > that to become the case with PHP, more than it already is.
>

+1


> > 2.) Would it possible that instead of adding operator overloading we
> could
> > add classes that could be extended where PHP actually defines the
> operators
> > for those classes?
>

+1.


> In any case, it is certainly possible that we could instead implement som=
e
> magic *objects* which can be extended that have built-in overloading in
> specific ways. I think this is actually worse for the following reasons:
>
> 1. It would be far less obvious to the programmer that an object would
> behave differently with a given operator, because the behavior wouldn't b=
e
> documented in the code itself.
>

For my vision, this point doesn't make sense. After reading my reply if
this still holds true please extend upon it if possible.

3. It would likely result in some maintainability concerns as more users
> demanded different DSL type implementations be included in core, and the
> existing ones would need to be maintained.
>

True, but I see this as a good thing. The bar to bring something into core
is so high that this is a protective layer against overdoing it.


> As I've mentioned, while I understand that to many programmers
> commutativity is a requirement of a good language, it is explicitly
> incorrect to require commutativity for math operations. The arithmetic
> operators are commutative for the real numbers, but there are many valid
> math concepts for which they are not commutative, and I feel like pushing
> for commutativity is a mistake. It is an attempt to force a behavior that
> we want on code that it may be incorrect for.
>

Totally with you here.


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.

Number:
0
1
27
-30
14 + i
f(x)
7/0 (joking!)
10!
15/8
3.141592...
0.9999999999999...
45=C2=B0
|-10|
log(n)


NumberCollection
Matrices
Sets
Expression


We have precedence for this: Datetime objects provided by PHP have operator
overloading. However it might be best for PHP to steer away from the
implementation and provide the abstract classes so that userland implements
them. These classes would allow operator overloading and if possible maybe
even a small hint of method overloading?

```
public function __add(Number $number): Number|NumberCollection
{

}

public function __add(NumberCollection $number): Number|NumberCollection
{

}
```

I confess I may be oversimplifying it too much, but I thought it was worth
asking. This could still be abused for crazy stuff, but by using
inheritance we make a best effort to delimit the scope into a mathematical
context.

My opinion is that operator overloading is bad for the language and is a
must-have feature for mathematical context. This seem to be the closest to
a common ground I can find.

--0000000000004c9bb505c9097243--