Operator overloading for userspace objects View as Markdown

I think that the left operand is the "owner", the magic method handler,
while the right operand is the argument.

So for $object * 5, we will have:

// $object instance
public function __multiply($number): self {
return $this->multiply($number);
}

But for 5 * $object we will have an error. Call order should be respected
now once that will be impossible you have $objectA * $objectB without
defines a priority (the main handler).

--
Atenciosamente,
David Rodrigues

Em ter., 28 de jan. de 2020 às 20:14, jan.h.boehmer@gmx.de escreveu:

Hello everybody,

the last days I have experimented a bit with operator overloading in
userspace classes (redefing the meaning of arithmetic operations like +, -,
*, etc. for your own classes).

This could be useful for different libraries which implements custom
arithmetic objects (like money values, tensors, etc.) or things like
Symfony
string component (concatenate) operator, because it improves readability
much:

$x * ($a + $b) instead of $x->multiply($a->add($b))

4 years ago, there was a RFC about this topic (
https://wiki.php.net/rfc/operator-overloading
https://wiki.php.net/rfc/operator-overloading), which was discussed a bit
(
https://externals.io/message/89967 https://externals.io/message/89967),
but there was no real Outcome.

I have tried to implement a proof of concept of the RFC, I encountered some
problems, when implementing the operator functions as (non-static) class
members and pass them only the “other” argument: What happens when we
encounter an expression like 2/$a and how can the class differ this from
$a/2. Also not every operation on every structure is e.g on commutative
(e.g. for matrices AB =/= BA). So I tried a C#-like approach, where the
operator implementations are static functions in the class, and both
arguments are passed. In my PHP implementation this would look something
like this:

Class X {

public static function __add($lhs, $rhs) {

            //...

}

}

The class function can so decide what to do, based on both operands (so it
can decide if the developer wrote 2/$a or $a/2). Also that way an
implementor can not return $this by accident, which could lead to
unintended
side effect, if the result of the operation is somehow mutated.

I have taken over the idea of defining a magic function for each operation
(like Python does), because I think that way it is the clearest way to see,
what operators a class implements (could be useful for static analysis).
The
downside to this approach is that this increases the number of magic
functions highly (my PoC-code defines 13 additional magic functions, and
the
unary operators are missing yet), so some people in the original discussion
suggest to define a single (magic) function, where the operator is passed,
and the user code decides, what to do. Advantageous is very extensible
(with
the right parser implementation, you could even define your own new
operators), with the cost that this method will become very complex for
data
structures which use multiple operators (large if-else or switch
constructions, which delegate the logic to the appropriate functions). An
other idea mentioned was to extract interfaces with common functionality
(like Arithmetically, Comparable, etc.) like done with the ArrayAccess or
Countable interfaces. The problem that I see here, is that this approach is
rather unflexible and it would be difficult to extract really universal
interfaces (e.g. vectors does not need a division (/) operation, but the
concatenation . could be really useful for implementing dot product). This
would lead to either that only parts of the interfaces are implemented (and
the other just throw exceptions) or that the interfaces contain only one or
two functions (so we would have many interfaces instead of magic functions
in the end).

On the topic which operators should be overloadable: My PoC-implementation
has magic functions for the arithmetic operators (+, -, *, /, %, **),
string
concatenation (.), and bit operations (>>, <<, &, |, ^). Comparison and
equality checks are implement using a common __compare() function, which
acts like an overload of the spaceship operator. Based if -1, 0 or +1 is
returned by the comparison operators (<, >, <=, >=, ==) are evaluated. I
think this way we can enforce, that the assumed standard logic (e.g
!($a<$b)=($a>=$b) and ($a<$b)=($b>$a)) of comparison is implemented. Also I
don’t think this would restrict real world applications much (if you have
an
example, where a separate definition of < and >= could be useful, please
comment it).

Unlike the original idea, I don’t think it should be possible to overwrite
identity operator (===), because it should always be possible to check if
two objects are really identical (also every case should be coverable by
equality). The same applies to the logic operators (!, ||, &&), I think
they
should always work like intended (other languages like Python and C#
handles
it that way too).

For the shorthand assignment operators like +=, -= the situation is a bit
more complicated: On the one hand the user has learned that $a+=1 is just
an
abbreviation of $=$a+1, so this logic should apply to overloaded operators
as well (in C# it is implemented like this). On the other hand it could be
useful to differentiate between the two cases, so you can mutate the object
itself (in the += case) instead of returning a new object instance (the
class cannot know it is assigned to its own reference, when $a + 1 is
called). Personally I don’t think that this would be a big problem, so my
PoC-Code does not provide a possibility to override the short hand
operators.) For the increment/decrement operators ($a++) it is similar, it
would be nice if it would be possible to overload this operator but on the
other hand the use cases of this operator is really limited besides integer
incrementation and if you want to trigger something more complex, you
should
call a method, to make clear of your intent.

On the topic in which order the operators should be executed: Besides the
normal priority (defined by PHP), my code checks if the element on the left
side is an object and tries to call the appropriate magic function on it.
If
this is not possible the same is done for the right argument. This should
cover the most of the use cases, except some cases: Consider a expression
like $a / $b, where $a and $b has different classes (class A + class B). If
class B knows how to divide class A, but class A does not know about class
B, we encounter a problem when evaluating just from left to right (and
check
if the magic method exists). A solution for that would be that object $a
can
express that he does not know how to handle class B (e.g. by returning
null,
or throwing a special exception) and PHP can call the handler on object $b.
I'm not sure how common this problem would be, so I don’t have an idea how
useful this feature would be.

My proof-of-concept implementation can be found here:
https://github.com/jbtronics/php-src
https://github.com/jbtronics/php-src

Here you can find some basic demo code using it:
https://gist.github.com/jbtronics/ee6431e52c161ddd006f8bb7e4f5bcd6
https://gist.github.com/jbtronics/ee6431e52c161ddd006f8bb7e4f5bcd6

I would be happy to hear some opinions for this concept, and the idea of
overloadable operators in PHP in general.

Thanks and Best regards,

Jan Böhmer

Hello everybody,

the last days I have experimented a bit with operator overloading in
userspace classes (redefing the meaning of arithmetic operations like +, -,
*, etc. for your own classes).

This could be useful for different libraries which implements custom
arithmetic objects (like money values, tensors, etc.) or things like Symfony
string component (concatenate) operator, because it improves readability
much:

$x * ($a + $b) instead of $x->multiply($a->add($b))

4 years ago, there was a RFC about this topic (
https://wiki.php.net/rfc/operator-overloading
https://wiki.php.net/rfc/operator-overloading), which was discussed a bit (
https://externals.io/message/89967 https://externals.io/message/89967),
but there was no real Outcome.

I have tried to implement a proof of concept of the RFC, I encountered some
problems, when implementing the operator functions as (non-static) class
members and pass them only the “other” argument: What happens when we
encounter an expression like 2/$a and how can the class differ this from
$a/2. Also not every operation on every structure is e.g on commutative
(e.g. for matrices AB =/= BA). So I tried a C#-like approach, where the
operator implementations are static functions in the class, and both
arguments are passed. In my PHP implementation this would look something
like this:

Class X {

public static function __add($lhs, $rhs) {

           //...

}

}

The class function can so decide what to do, based on both operands (so it
can decide if the developer wrote 2/$a or $a/2). Also that way an
implementor can not return $this by accident, which could lead to unintended
side effect, if the result of the operation is somehow mutated.

I have taken over the idea of defining a magic function for each operation
(like Python does), because I think that way it is the clearest way to see,
what operators a class implements (could be useful for static analysis). The
downside to this approach is that this increases the number of magic
functions highly (my PoC-code defines 13 additional magic functions, and the
unary operators are missing yet), so some people in the original discussion
suggest to define a single (magic) function, where the operator is passed,
and the user code decides, what to do. Advantageous is very extensible (with
the right parser implementation, you could even define your own new
operators), with the cost that this method will become very complex for data
structures which use multiple operators (large if-else or switch
constructions, which delegate the logic to the appropriate functions). An
other idea mentioned was to extract interfaces with common functionality
(like Arithmetically, Comparable, etc.) like done with the ArrayAccess or
Countable interfaces. The problem that I see here, is that this approach is
rather unflexible and it would be difficult to extract really universal
interfaces (e.g. vectors does not need a division (/) operation, but the
concatenation . could be really useful for implementing dot product). This
would lead to either that only parts of the interfaces are implemented (and
the other just throw exceptions) or that the interfaces contain only one or
two functions (so we would have many interfaces instead of magic functions
in the end).

On the topic which operators should be overloadable: My PoC-implementation
has magic functions for the arithmetic operators (+, -, *, /, %, **), string
concatenation (.), and bit operations (>>, <<, &, |, ^). Comparison and
equality checks are implement using a common __compare() function, which
acts like an overload of the spaceship operator. Based if -1, 0 or +1 is
returned by the comparison operators (<, >, <=, >=, ==) are evaluated. I
think this way we can enforce, that the assumed standard logic (e.g
!($a<$b)=($a>=$b) and ($a<$b)=($b>$a)) of comparison is implemented. Also I
don’t think this would restrict real world applications much (if you have an
example, where a separate definition of < and >= could be useful, please
comment it).

Unlike the original idea, I don’t think it should be possible to overwrite
identity operator (===), because it should always be possible to check if
two objects are really identical (also every case should be coverable by
equality). The same applies to the logic operators (!, ||, &&), I think they
should always work like intended (other languages like Python and C# handles
it that way too).

For the shorthand assignment operators like +=, -= the situation is a bit
more complicated: On the one hand the user has learned that $a+=1 is just an
abbreviation of $=$a+1, so this logic should apply to overloaded operators
as well (in C# it is implemented like this). On the other hand it could be
useful to differentiate between the two cases, so you can mutate the object
itself (in the += case) instead of returning a new object instance (the
class cannot know it is assigned to its own reference, when $a + 1 is
called). Personally I don’t think that this would be a big problem, so my
PoC-Code does not provide a possibility to override the short hand
operators.) For the increment/decrement operators ($a++) it is similar, it
would be nice if it would be possible to overload this operator but on the
other hand the use cases of this operator is really limited besides integer
incrementation and if you want to trigger something more complex, you should
call a method, to make clear of your intent.

On the topic in which order the operators should be executed: Besides the
normal priority (defined by PHP), my code checks if the element on the left
side is an object and tries to call the appropriate magic function on it. If
this is not possible the same is done for the right argument. This should
cover the most of the use cases, except some cases: Consider a expression
like $a / $b, where $a and $b has different classes (class A + class B). If
class B knows how to divide class A, but class A does not know about class
B, we encounter a problem when evaluating just from left to right (and check
if the magic method exists). A solution for that would be that object $a can
express that he does not know how to handle class B (e.g. by returning null,
or throwing a special exception) and PHP can call the handler on object $b.
I'm not sure how common this problem would be, so I don’t have an idea how
useful this feature would be.

My proof-of-concept implementation can be found here:
https://github.com/jbtronics/php-src https://github.com/jbtronics/php-src

Here you can find some basic demo code using it:
https://gist.github.com/jbtronics/ee6431e52c161ddd006f8bb7e4f5bcd6
https://gist.github.com/jbtronics/ee6431e52c161ddd006f8bb7e4f5bcd6

I would be happy to hear some opinions for this concept, and the idea of
overloadable operators in PHP in general.

On the subject of mutation, it seems awkward to me that $a + 1 would alter the value of $a or that 2/$b should alter $b. Rather, I would expect a new value to be returned as a result of this operation.

If you take mutation off the table, then things become easier, IMO. We only need two magic methods:

• __toInteger(): int
• __toFloat(): float

Then, in any mathematical context, PHP could call the appropriate method and use the number returned in the calculation.

So, we could have something like this:

class MyNumber
{
public function __toInteger(): int
{
return (int) $this->number;
}
}

$x = new MyNumber(1);
$y = $x + 1;

And the value of $y would be 2.

Of course, there’s the question of what we do if a class defines both __toInteger() and __toFloat(), so perhaps a __toNumber() is more appropriate, though that leads us into discussions what the return type of this method should be and whether a number scalar type is needed, but I think I’m getting ahead of the discussion here.

TL;DR: mutating an object in the context of a mathematical operation (unless I’m explicitly calling a method on the object with the expectation of mutating it) could result in confusing and unexpected results for programmers.

Cheers,
Ben

Hello everybody,

the last days I have experimented a bit with operator overloading in
userspace classes (redefing the meaning of arithmetic operations like +, -,
*, etc. for your own classes).

This could be useful for different libraries which implements custom
arithmetic objects (like money values, tensors, etc.) or things like
Symfony
string component (concatenate) operator, because it improves readability
much:

$x * ($a + $b) instead of $x->multiply($a->add($b))

4 years ago, there was a RFC about this topic (
https://wiki.php.net/rfc/operator-overloading
https://wiki.php.net/rfc/operator-overloading), which was discussed a bit
(
https://externals.io/message/89967 https://externals.io/message/89967),
but there was no real Outcome.

I have tried to implement a proof of concept of the RFC, I encountered some
problems, when implementing the operator functions as (non-static) class
members and pass them only the “other” argument: What happens when we
encounter an expression like 2/$a and how can the class differ this from
$a/2. Also not every operation on every structure is e.g on commutative
(e.g. for matrices AB =/= BA). So I tried a C#-like approach, where the
operator implementations are static functions in the class, and both
arguments are passed. In my PHP implementation this would look something
like this:

Class X {

public static function __add($lhs, $rhs) {

            //...

}

}

The class function can so decide what to do, based on both operands (so it
can decide if the developer wrote 2/$a or $a/2). Also that way an
implementor can not return $this by accident, which could lead to
unintended
side effect, if the result of the operation is somehow mutated.

Using static methods sounds reasonable to me.

I have taken over the idea of defining a magic function for each operation

(like Python does), because I think that way it is the clearest way to see,
what operators a class implements (could be useful for static analysis).
The
downside to this approach is that this increases the number of magic
functions highly (my PoC-code defines 13 additional magic functions, and
the
unary operators are missing yet), so some people in the original discussion
suggest to define a single (magic) function, where the operator is passed,
and the user code decides, what to do. Advantageous is very extensible
(with
the right parser implementation, you could even define your own new
operators), with the cost that this method will become very complex for
data
structures which use multiple operators (large if-else or switch
constructions, which delegate the logic to the appropriate functions). An
other idea mentioned was to extract interfaces with common functionality
(like Arithmetically, Comparable, etc.) like done with the ArrayAccess or
Countable interfaces. The problem that I see here, is that this approach is
rather unflexible and it would be difficult to extract really universal
interfaces (e.g. vectors does not need a division (/) operation, but the
concatenation . could be really useful for implementing dot product). This
would lead to either that only parts of the interfaces are implemented (and
the other just throw exceptions) or that the interfaces contain only one or
two functions (so we would have many interfaces instead of magic functions
in the end).

Yes, i don't think it makes sense to group these operations in interfaces,
the use-cases are just too diverse. It's possible to define one interface
per operator (e.g. what Rust does), though I don't think this is going to
be particularly useful in PHP. I would not want to see functions accepting
int|float|(Add&Mul) show up, because someone is trying to be overly generic
in their interfaces ;)

As to whether it should be a single method or multiple, I would go for
multiple methods, as that makes it more clear which operators are
overloaded from an API perspective.

On the topic which operators should be overloadable: My PoC-implementation

has magic functions for the arithmetic operators (+, -, *, /, %, **),
string
concatenation (.), and bit operations (>>, <<, &, |, ^). Comparison and
equality checks are implement using a common __compare() function, which
acts like an overload of the spaceship operator. Based if -1, 0 or +1 is
returned by the comparison operators (<, >, <=, >=, ==) are evaluated. I
think this way we can enforce, that the assumed standard logic (e.g
!($a<$b)=($a>=$b) and ($a<$b)=($b>$a)) of comparison is implemented. Also I
don’t think this would restrict real world applications much (if you have
an
example, where a separate definition of < and >= could be useful, please
comment it).

I would recommend not handling overloading of comparisons in the same
proposal. Comparison is more widely useful than other overloading and has a
more complex design space (especially when it comes to accommodating
objects that can only be compared for equality/inequality for example).
Comparison may also benefit more from having an interface than the other
operators.

Unlike the original idea, I don’t think it should be possible to overwrite
identity operator (===), because it should always be possible to check if
two objects are really identical (also every case should be coverable by
equality). The same applies to the logic operators (!, ||, &&), I think
they
should always work like intended (other languages like Python and C#
handles
it that way too).

I agree that === should not be overloadable. || and && are
short-circuiting, so overloading them in any meaningful way would be pretty
hard anyway (we'd have to implicitly wrap the RHS into a closure or ...
something?)

For the shorthand assignment operators like +=, -= the situation is a bit
more complicated: On the one hand the user has learned that $a+=1 is just
an
abbreviation of $=$a+1, so this logic should apply to overloaded operators
as well (in C# it is implemented like this). On the other hand it could be
useful to differentiate between the two cases, so you can mutate the object
itself (in the += case) instead of returning a new object instance (the
class cannot know it is assigned to its own reference, when $a + 1 is
called). Personally I don’t think that this would be a big problem, so my
PoC-Code does not provide a possibility to override the short hand
operators.) For the increment/decrement operators ($a++) it is similar, it
would be nice if it would be possible to overload this operator but on the
other hand the use cases of this operator is really limited besides integer
incrementation and if you want to trigger something more complex, you
should
call a method, to make clear of your intent.

At least to start with, I don't think we should offer separate overloading
of $a += 1 and treat it as $a = $a +1, as the existing operator overloading
implementation does. Operators currently only work on values that use
by-value passing semantics, so if you write something like

$b = $a = 1;
$a += 1;

then $a will be 2, but $b will be 1. Using the $a = $a + 1 expansion for
operator overloading ensures that this is also the case for objects.

Of course there are performance concerns here, and it could in some cases
be significantly more efficient to perform an in-place modification. It is
possible to allow that while still keeping the above semantics by only
allowing an in-place modification if $a has no over users (something that
we can check in the VM). But I don't think this should be part of an
initial proposal.

On the topic in which order the operators should be executed: Besides the
normal priority (defined by PHP), my code checks if the element on the left
side is an object and tries to call the appropriate magic function on it.
If
this is not possible the same is done for the right argument. This should
cover the most of the use cases, except some cases: Consider a expression
like $a / $b, where $a and $b has different classes (class A + class B). If
class B knows how to divide class A, but class A does not know about class
B, we encounter a problem when evaluating just from left to right (and
check
if the magic method exists). A solution for that would be that object $a
can
express that he does not know how to handle class B (e.g. by returning
null,
or throwing a special exception) and PHP can call the handler on object $b.
I'm not sure how common this problem would be, so I don’t have an idea how
useful this feature would be.

That sounds reasonable to me.

My proof-of-concept implementation can be found here:
https://github.com/jbtronics/php-src
https://github.com/jbtronics/php-src

Unfortunately, this implementation goes in the wrong direction: PHP already
has full internal support for operator overloading through the do_operation
object handler. Operator overloading should be exposed to userland through
that handler as well.

Here you can find some basic demo code using it:
https://gist.github.com/jbtronics/ee6431e52c161ddd006f8bb7e4f5bcd6
https://gist.github.com/jbtronics/ee6431e52c161ddd006f8bb7e4f5bcd6

I would be happy to hear some opinions for this concept, and the idea of
overloadable operators in PHP in general.

Thanks for working on this :) I think overloaded operators are a reasonable
addition to the language at this point. I think the main concern people
tend to have in this area is that operator overloading is going to be
abused (see for example << in C++). There are many very good use-cases for
operator overloading though (as mentioned, vector/matrix calculations,
complex, rationals, money, ...) Some of those are not common in PHP, but
maybe the lack of operator overloading is part of the problem there ;)

Regards,
Nikita

the last days I have experimented a bit with operator overloading in
userspace classes (redefing the meaning of arithmetic operations like

Some historic context: I am probably the one who did operator
overloading in PHP first. Oldest trace is this post:
https://markmail.org/message/y7rq5vcd5ucsbcyb

Here you can find some basic demo code using it:
https://gist.github.com/jbtronics/ee6431e52c161ddd006f8bb7e4f5bcd6
https://gist.github.com/jbtronics/ee6431e52c161ddd006f8bb7e4f5bcd6

This example can be used to show a major problem for PHP doing this.

The first problem is that PHP historically had very few type
annotations making the code hard to predict, modern PHP has more of
that reducing this a bit, but the big problem remains: In PHP we can't
overload functions, thus operators have to be member functions and
therefore form a closed set.

In your example the vector3 can operate on vector3s.

$a = new Vector3(1, 2, 3);
$b = new Vector3(3, 2, 1);

$c = $a * $b;

Within Vector3 that is complete. But maths allows multiplication with
integers. So, yes, you can extend your __mul() with a check for the rhs
as you did with the is_numeric, but why would

$c = 2 * $a;

call the Vecotr3's operator function? I believe it would call integer's
operator. Which obviously doesn't exist.

But okay, let's do a hack for integer, to call the second arguments
operator if first argument is an integer.

Now I come and really like your vector3 library and create my Matrix
type. With my Matrix i want to still use your Vector3.

include 'your/vector3.php';
class Matrix {
public static function __mul($lhs, $rhs) { ... }
}

$vec = new Vector3(...);
$matrix = new Matrix(...);

$result = $vec * $matrix;

Which one is being called? - Vector's or Matrix's. How will your
vector know about my Matrix?

The way C++ solves this is by allowing non-member functions as
operators.

 #include "vector3.h" // provides class Vector3
 #include "matrix.h"  // provides class Matrix, potentially
                      //  from a different vendor

 Matrix operator*(const Vector3 &lhs, const Matrix &rhs) {
     // I can provide  this myself if neither Vctor's nor
     // Matrix's vendor do
     return ...;
 }

 int main() {
     Vector3 vec{...};
     Matrix matrix{....};

      // works
      auto result = vec * matrix;
 }

To make this really work C++ has another magic, aside from function
overloading, which is ADL - Argument depending lookup, which is the
black magic of C++: If The function to be called is not only looked for
in the current or global namespace, but also the namespace of the first
Argument. So this works:

namespace JohannesCoolLibrary {
    class Vector;

    void func(Vector v);
    Vector operator*(Vector lhs, Vector rhs);
}

namespace SomeOtherCoolThing {
    JohannesCoolLibrary::Vector v1{};
    JohannesCoolLibrary::Vector v2{};

    v1 * v2; // will find the operator in the namespace
             // even though it's using the global name

    func(v1); // will also call function from argument's namnespace
}

Without these features you can only create closed types, which
massively limit interoperability, which massively limits the use cases
for operator overloading.

With limited set of use cases, this is a rare feature, which is hard to
understand, or how many internals reads do you expect immediately know
the output of

function a($a, $b) {
    return $a + $b;
}

var_dump(a([1], [2]));

johannes