PHP Internals News: Episode 96: User Defined Operator Overloads

PHP Internals News: Episode 96: User Defined Operator
Overloads



Thursday, December 16th 2021, 09:24 GMT


London, UK



In this episode of "PHP Internals News" I chat with
Jordan LeDoux (GitHub) about the "User Defined Operator
Overloads" RFC.


The RSS feed for this podcast is
https://derickrethans.nl/feed-phpinternalsnews.xml, you
can download this episode's MP3 file, and it's available
on Spotify and iTunes. There is a dedicated website:
https://phpinternals.news


Transcript

Derick Rethans 0:14

Hi, I'm Derick. Welcome to PHP internals news, a
podcast dedicated to explaining the latest
developments in the PHP language. This is episode 96.
Today I'm talking with Jordan, about a user defined
operator overloads RFC that he's proposing. Jordan,
would you please introduce yourself?
Jordan LeDoux 0:33

My name is Jordan LeDoux. I've been working in PHP
for quite a while now. This is the second time I have
ventured to propose an RFC.
Derick Rethans 0:44

What was the first one?
Jordan LeDoux 0:45

The first one was the "never for parameter types",
which was much more exploratory. And we talked about
it a little bit. And it generated a lot of good
discussion that contributed to kind of the idea
formation, which was what I hope to get out of it.
Derick Rethans 1:01

Okay, but that didn't end up making it into a PHP
release. As far as I understand, right?
Jordan LeDoux 1:07

No, I withdrew it actually, it was clear that the
better way to approach the problem it was trying to
solve was with a much more comprehensive solution.
That particular solution was something that only
required a seven line change to the engine. So I
wanted to see if it was something people were okay
with, or thought was a decent idea for that
particular problem, much more comprehensive, like
template classes, or something like that is probably
the better route to go.
Derick Rethans 1:35

Well, I think the RFC that we're talking about today,
is going to require quite a bit more than seven lines
of code?
Jordan LeDoux 1:41

Quite a bit more. Yeah.
Derick Rethans 1:42

So what is this RFC that we're talking about today?
Jordan LeDoux 1:45

Well, user defined operator overloads is a way for
PHP developers to define the ways in which objects
interact with specific operators. So for instance,
the plus operator, the plus sign. It's a way for
those objects to kind of define their own logic as
far as how that's handled, which right now, as of PHP
8.0, those were all switched to type errors. So it's
not possible currently to write any code that doesn't
result in a fatal error, where objects are used with
operators.
Derick Rethans 2:25

Usually, I ask about every RFC, what problem are you
trying to solve this? So what problem are you trying
to solve this RFC?
Jordan LeDoux 2:31

The biggest problem that this solves is that objects
contain, so objects in most programs represent a
value or multiple values that have a program context.
That's the most powerful thing about objects is
they're contextual, and they understand the state,
they understand what state the object is in, and
sometimes even what state the whole program is in.
And that's necessary for a lot of things. Like for
instance, if you're tracking a distance, you know,
you might measure that meters, and that would have a
number you might have 30 meters of distance, but it
also has a unit of meters. You could just represent
that as an int. And then the program just knows
internally, hey this is always in meters. But if you
need to convert that to a different unit, then that
becomes: Okay, well, now I need a special case some
things, or I need a function just for converting, and
I need to remember which unit my number is in. In a
lot of cases, you handle that with objects because
objects understand state, and they understand state
transitions, which is what a lot of methods are
about; transitioning the state of the object from one
state to another. Operators are also about state
transitions. And they're about very specific kinds of
state transitions. It's natural in a lot of ways to
think that you, you should be able to define how
those two things interact. But currently, it's just
not possible within PHP.
Derick Rethans 4:00

Well, does them this magic operator overloading?
Jordan LeDoux 4:04

It allows PHP developers to define an implementation
logic, which is much like you define a function body
that describes how does this object interact with
this operator. That's essentially it. There's a lot
of other details as to how it does that and what are
the restrictions, but that's really the core of the
idea.
Derick Rethans 4:26

And in what kind of situations would you use that?
Jordan LeDoux 4:28

A lot of them are situations where you're doing very
complicated mathematics, or scientific computing or
machine learning or things of that nature, where you
are going to routinely encounter numbers that have
state to them or that have multiple dimensions to
them. So for instance, vector mathematics is one
where the way that vectors interact with a lot of the
operators that we're familiar with, like the
multiplication sign is very different than how the
number five interacts with the multiplication sign.
Complex numbers is another one, you know, to multiply
two complex numbers together, you have to treat it
like a polynomial where you're multiplying it with
the FOIL method: first, outside, inside, last. You
know, there's a lot of those sorts of circumstances.
But it also could potentially be very useful for some
things that are not really mathematical but more
quality of life for PHP developers. For instance,
scalar objects is something that a lot of developers
in PHP have, you know, wanted for a while. It's a
thing that's a little more difficult to pin down, how
exactly would you go about doing this within the
engine, and it's a thing that the engine would kind
of have to be very opinionated about by its nature.
PHP developers can't provide their own scalar
objects. And the main reason for this is that scalars
interact with operators and objects can't. So simply
allowing PHP developers to define a way for objects
to interact with operators would allow user land to
develop their own scalar object replacements. It
wouldn't make every scalar that object; scalar
objects within the engine still has, it's a separate
feature. And it's still a thing that would be
desirable, probably to a lot of people. But it gets
quite a bit of the way there.
Derick Rethans 6:20

It is always interesting that people come up with the
example of complex numbers, because I'm not sure how
useful that is in a PHP user land context. And then
beyond the scalars, I then sometimes struggle to see
where this could be used. With the only exception is
probably doing calculations with money related
issues. The moment you bring up operator overloading,
you'll also get people to say that this is going to
get abused. Examples of that, in my opinion at least,
is where in C++ you have like the