# [VOTE] Userspace operator overloading

- Thread: https://externals.io/message/109241
- Original archive: https://news-web.php.net/php.internals/109241
- Started by jan.h.boehmer@gmx.de on 2020-03-23T17:58:06+00:00
- Messages: 44
- RFC: Userspace Operator overloading (Declined) — https://externals.io/rfc/userspace_operator_overloading.md
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/109241.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #109241 — jan.h.boehmer@gmx.de — 2020-03-23T17:58:06+00:00

URL: https://externals.io/message/109241#109241

Hi internals,

I have opened voting on
https://wiki.php.net/rfc/userspace_operator_overloading, which allows users
to overload operators in their own classes.

Voting closes on 2020-04-06.

Regards,
Jan Böhmer

---

## #109263 — Marco Pivetta — 2020-03-24T10:03:46+00:00

URL: https://externals.io/message/109241#109263 · In reply to: #109241

Hey Jan,

Just posting here why I voted "no": it is not your implementation proposal,
but rather the concept per-se that IMO shouldn't land in the language.

Operator overloading makes call-site code reading extremely hard, and it
makes the language much more complex for very little benefit.

Everything suggested in the RFC can be done by using explicit arrows: `->`
(method calls), which lead to expressively named methods and parameters.

I have posted similar thoughts about `->__toString()` and `->toString()`
when it comes to cast operations vs explicit calls at
https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229

Overall, without type classes and infix functions, operator overloading is,
IMO, just messy.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/




> Hi internals,
>
> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows
> users
> to overload operators in their own classes.
>
> Voting closes on 2020-04-06.
>
> Regards,
> Jan Böhmer

---

## #109264 — Sebastian Bergmann — 2020-03-24T10:06:52+00:00

URL: https://externals.io/message/109241#109264 · In reply to: #109263

Am 24.03.2020 um 11:03 schrieb Marco Pivetta:
> Just posting here why I voted "no": it is not your implementation proposal,
> but rather the concept per-se that IMO shouldn't land in the language.

I voted "no" for the same reason.

---

## #109266 — Nikita Popov — 2020-03-24T10:41:57+00:00

URL: https://externals.io/message/109241#109266 · In reply to: #109241

> Hi internals,
>
> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows
> users
> to overload operators in their own classes.
>
> Voting closes on 2020-04-06.
>
> Regards,
> Jan Böhmer
>

To offer a counter-point, I voted yes on this proposal. A couple of
thoughts:

1. This is exposing functionality that already exists for internal classes
to userland classes. As a general rule, I think we should always strive to
have behavioral parity between internal and userland classes.

2. Because this just exposes existing functionality, the amount of
technical complexity this introduces is very small, especially compared to
the significance of what this enables. The implementation complexity of
RFCs is increasingly becoming a problem, due to the complex way in which
existing language features interact. This RFC does not fall into that
category.

3. As mentioned, this functionality already exists internally and is used
by GMP, where it works (imho) very well. Of course, this is also something
of a poster-child use case for operator overloading, in that the object
literally represents a number. But there are plenty other similar examples,
some of them very relevant to PHP (money represention).

I think there is a somewhat irrational fear that operator overloading is
going to be misused... but having worked in quite a few languages that do
support operator overloading, I think I've only encountered this in two
instances: First, the infamous use of << and >> as stream operators in C++
(which is really horrible, and gives operator overloading a bad name
everywhere). And second, the use of / as a path concatenation operator in
some libraries. And I think that's it. All other uses I've worked with were
things like arbitrary-precision integers, floats, decimals or rationals;
complex numbers, vectors, matrixes or tensors; bit vectors, constant
ranges, known bits representations.

Operator overloading is not a feature that is commonly needed or should be
used much, but it does tend to make code a *lot* more readable in the cases
where it is useful.

I think people might also find this blog post by Guido interesting:
https://neopythonic.blogspot.com/2019/03/why-operators-are-useful.html

Regards,
Nikita

---

## #109268 — Mark Randall — 2020-03-24T11:14:28+00:00

URL: https://externals.io/message/109241#109268 · In reply to: #109241

> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows users
> to overload operators in their own classes.

I am certainly not opposed to operator overloading, and would like to 
see it in the language.

However, I'll be voting no because of a couple of implementation points:

1. I feel like the choice of `NULL` as the return type for not implemented 
is far from ideal, especially for 8.0 which provides for union type hints.

2. The error handling behaviour is too timid. If operator overloading is 
to become a first-class feature, error handling should reflect as such 
and any attempt to use objects without the appropriate handlers being 
installed really should result in an error being thrown just as it would 
be if an undefined method was called.

Mark Randall

---

## #109284 — Benjamin Eberlei — 2020-03-25T10:44:38+00:00

URL: https://externals.io/message/109241#109284 · In reply to: #109241

> Hi internals,
>
> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows
> users
> to overload operators in their own classes.
>
> Voting closes on 2020-04-06.
>
> Regards,
> Jan Böhmer
>

Thank you.

I voted yes on this for similar reasons than Nikita. I think it is
confusing to users why internal objects can overload these and userland
can't.

The simplicity of exposing this is another plus.

The potential for misuse is a non issue for me, because essentially this
applies to most features, especially with existing magic methods we have a
precedent that we can build upon instead of "repressing use".

---

## #109287 — Nicolas Grekas — 2020-03-25T11:23:43+00:00

URL: https://externals.io/message/109241#109287 · In reply to: #109266

> 1. This is exposing functionality that already exists for internal classes
>

2. Because this just exposes existing functionality, the amount of
> technical complexity this introduces is very small
>


> 3. As mentioned, this functionality already exists internally and is used
> by GMP, where it works (imho) very well.
>

Thanks Nikita for the insights, that's really helpful.

I'd suggest removing the "PHP_OPERAND_TYPES_NOT_SUPPORTED" constant and
settle on null instead.
The reason is visible in the RFC: `public static function __mul($lhs, $rhs):
?Vector3` - nothing else than null can be returned here when looking at the
return type. Returning a const is just calling for "WTF" indirections IMHO.

I'm still voting yes, hoping for this const to be removed after if the RFC
passes, if it does :)

Nicolas

---

## #109288 — Christoph M. Becker — 2020-03-25T11:28:42+00:00

URL: https://externals.io/message/109241#109288 · In reply to: #109241

> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows users
> to overload operators in their own classes.

It seems to me that the RFC is not sufficiently specific enough
regarding the concatenation of instances of classes which implement
__toString().  The RFC itself doesn't mention that explicitly, and the
backward incompatible changes section states:

| As long as the user does not implement, the operator magic functions,
| operators on objects will behave in the previous way.

However, at least the current implementation raises two notices ("You
have to implement the __concat function") when concatenating Stringable
objects.

A minor issue: in my opinion, introducing
PHP_OPERAND_TYPES_NOT_SUPPORTED doesn't make sense.  The RFC says:

| Handlers can specify return typehints, but note that the return type
| has to be nullable (as PHP_OPERAND_TYPES_NOT_SUPPORTED has the value
| null).

So if we ever wanted to change the value of
PHP_OPERAND_TYPES_NOT_SUPPORTED, we'd introduce a BC break.  Therefore
the constant's value likely will never change, so using `NULL` directly to
signal unsupported operand types would be fine, wouldn't it?

--
Christoph M. Becker

---

## #109290 — Alexander Lisachenko — 2020-03-25T12:25:32+00:00

URL: https://externals.io/message/109241#109290 · In reply to: #109241

Hi, internals!

I want to mention, that all existing internal API of Zend could be
accessible via FFI as of PHP7.4. This gives opportunity to implement
userspace operator overloading as a simple PHP package.

I know, that FFI requires some polishing, but it could become a tool to
create interesting extensions via Z-Engine or similar libraries. Just for
example, I have a repository
https://github.com/lisachenko/native-types which provides an example of
userspace operator-overloading for matrices (see __doOperation method
implementation at
https://github.com/lisachenko/native-types/blob/master/src/Matrix.php#L232-L276
)

Please share you thoughts about this.

Best regards,
Alexander

пн, 23 мар. 2020 г. в 20:58, <jan.h.boehmer@gmx.de>:

> Hi internals,
>
> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows
> users
> to overload operators in their own classes.
>
> Voting closes on 2020-04-06.
>
> Regards,
> Jan Böhmer

---

## #109320 — Jakob Givoni — 2020-03-26T02:49:44+00:00

URL: https://externals.io/message/109241#109320 · In reply to: #109288

>
> It seems to me that the RFC is not sufficiently specific enough
> regarding the concatenation of instances of classes which implement
> __toString().

Exactly what I was thinking too. Would be nice with some examples on this.

> So if we ever wanted to change the value of
> PHP_OPERAND_TYPES_NOT_SUPPORTED, we'd introduce a BC break.  Therefore
> the constant's value likely will never change, so using `NULL` directly to
> signal unsupported operand types would be fine, wouldn't it?

Agree on this too.

---

## #109321 — Sebastian Bergmann — 2020-03-26T06:09:17+00:00

URL: https://externals.io/message/109241#109321 · In reply to: #109264

Am 24.03.2020 um 11:06 schrieb Sebastian Bergmann:
> I voted "no" for the same reason.

I changed my vote to "yes" because of Nikita's arguments.

---

## #109340 — jan.h.boehmer@gmx.de — 2020-03-26T16:37:02+00:00

URL: https://externals.io/message/109241#109340 · In reply to: #109320

> 
>
> > […]
>
> Exactly what I was thinking too. Would be nice with some examples on this.

I am not sure if I can (or should) still add this to the RFC, here some clarification on this:

The overloaded concat operator has higher priority than the __toString() method.
So if Class A overloades the concat operator, then calling $a . $b means ClassA::__concat($a, $b);  (Note that both operands are passed in their original form)
If you want to concat the string representations, you will have to explicitly convert the objects to strings: 
	$ret = (string) $a . (string) $b;

If the concat operator is not overloaded, the behavior is like now, and the objects are converted implicitly to strings (so $a . $b actually means (string) $a . (string) $b).
Furthermore an notice is triggered, hinting the user that he could overload the concat operator. (Maybe here a different message than for the other operators would be useful).

---

## #109342 — Derick Rethans — 2020-03-26T16:52:16+00:00

URL: https://externals.io/message/109241#109342 · In reply to: #109241

> Hi internals,
> 
> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows users
> to overload operators in their own classes.

I've always been a strong proponent of operator overloading, but as PHP 
already has it internally, it makes sense to also make that information 
available for userland.

cheers,
Derick

---

## #109345 — Guilliam Xavier — 2020-03-26T17:18:58+00:00

URL: https://externals.io/message/109241#109345 · In reply to: #109340

>
> The overloaded concat operator has higher priority than the __toString() method.
> So if Class A overloades the concat operator, then calling $a . $b means ClassA::__concat($a, $b);  (Note that both operands are passed in their original form)
> If you want to concat the string representations, you will have to explicitly convert the objects to strings:
>         $ret = (string) $a . (string) $b;

This first part seems legit to me.

> If the concat operator is not overloaded, the behavior is like now, and the objects are converted implicitly to strings (so $a . $b actually means (string) $a . (string) $b).
> Furthermore an notice is triggered, hinting the user that he could overload the concat operator. (Maybe here a different message than for the other operators would be useful).

I fear that "hint" notice could break Symfony apps... Couldn't you
just not trigger it in this case?

-- 
Guilliam Xavier

---

## #109346 — Christoph M. Becker — 2020-03-26T17:25:56+00:00

URL: https://externals.io/message/109241#109346 · In reply to: #109345

> 
> > […]
>
> This first part seems legit to me.
>
> > […]
>
> I fear that "hint" notice could break Symfony apps... Couldn't you
> just not trigger it in this case?

Either that (it's what I would prefer), or clearly document that BC
break (even if it's just about a notice).

Thanks,
Christoph

---

## #109347 — jan.h.boehmer@gmx.de — 2020-03-26T17:36:27+00:00

URL: https://externals.io/message/109241#109347 · In reply to: #109345

> > […]
>
> I fear that "hint" notice could break Symfony apps... Couldn't you just not trigger it in this case?

Yes this would be possible and I think that it might be reasonable to omit the notice in this case (maybe only if the objects really implement a __toString).
What do others think about this?

Regards,
Jan

---

## #109349 — Derick Rethans — 2020-03-26T18:06:35+00:00

URL: https://externals.io/message/109241#109349 · In reply to: #109342

> 
> 
> > […]
> 
> I've always been a strong proponent of operator overloading, but as PHP 
                            ^^^^^^^^^
                                 I meant "opponent" there of course.
> already has it internally, it makes sense to also make that information 
> available for userland.

In any case, I am a +1!

cheers,
Derick

-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

---

## #109352 — michal.brzuchalski@gmail.com — 2020-03-26T19:02:25+00:00

URL: https://externals.io/message/109241#109352 · In reply to: #109241

pon., 23 mar 2020 o 18:58 <jan.h.boehmer@gmx.de> napisał(a):

> Hi internals,
>
> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows
> users
> to overload operators in their own classes.
>

I got two comments, a little late but always better than even later.

The first thing is for operator methods when the operation is not supported
I would see simply `return null;` as the right solution
instead of constant, which name no one will remember.

The second thing is notices which are confusing when suggesting to go
and implement overloaded operator method on extension derived classes
like stdClass like below:

Notice: You have to implement the __add function in class stdClass to use
this operator with an object in...

The text of the notice is not documented in the RFC but it is implemented
that way in the patch.
A PHP developer is not likely gonna download the php-src source code,
build environment and go with the ext/standard implementation and start
adding it in C.
The notice in this cases should either be different or not emitted at all.
If the latter then that has to be documented I guess.

Cheers,
--
Michał Brzuchalski

---

## #109355 — Matthew Brown — 2020-03-26T19:55:47+00:00

URL: https://externals.io/message/109241#109355 · In reply to: #109263

I accept that it adds an extra level of understanding to the language – if
you see

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

you no longer definitely know the answer will be numeric.

However, I imagine that the sorts of people who will use this are _also_
the sorts of people who would add type annotations clearly – so you'd much
more likely see

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

where it's trivial to understand that there's userspace operator
overloading going on.



> Hey Jan,
>
> Just posting here why I voted "no": it is not your implementation proposal,
> but rather the concept per-se that IMO shouldn't land in the language.
>
> Operator overloading makes call-site code reading extremely hard, and it
> makes the language much more complex for very little benefit.
>
> Everything suggested in the RFC can be done by using explicit arrows: `->`
> (method calls), which lead to expressively named methods and parameters.
>
> I have posted similar thoughts about `->__toString()` and `->toString()`
> when it comes to cast operations vs explicit calls at
>
> https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229
>
> Overall, without type classes and infix functions, operator overloading is,
> IMO, just messy.
>
> Greets,
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>
> 
>
> > […]

---

## #109376 — johannes@schlueters.de — 2020-03-27T20:10:01+00:00

URL: https://externals.io/message/109241#109376 · In reply to: #109241

> Hi internals,
> 
> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows
> users to overload operators in their own classes.
> 

I consider operator overlaoding in general a good feature (while PHP's
overload for + on arrays is weird)

However I don't like this design.

Consider this case: Some library provides a type A without overloads. I
then create a type B with overload:

    class B {
        static public __add($lhs, $rhs) {
            if ($lhs instanceof A) ... 
            elseif($rhs instanceof A) ...
            else error
        }
    } 

as I want my type's addition to commutative I handle this with some if
(probably dispatching. Now I can invoke it:

   new A() + new B(); // calls B::__add()
   new B() + new A(); // calls B::__add() as well

Now the maintainer of A implements the feature request "A should allow
addition with integers", I update my library and suddenly weird things
happen.

   new A() + new B(); // calls A::__add() and explodes, as A doesn't know  B
   new B() + new A(); // calls B::__add() works as before

Now we could establish the best practice that one type's operator calls
the other type's operator in case it can't handle a type. However that
is no good option as it will lead to infinite recursion if neither type
can handle both operands.


The issue is that by forcing type declarations as part of the class, as
members, this forms a closed set, but for many cases a strict closed
set isn't what one wants. For mathematical types having operators
working with integers (and other numeric values) is essential.
Communativity often also is required.  So a true closed set doesn't
work, for an open set can't be created easily in today's PHP. Thus the
RFC tries to tie this together, but this will fall apart and then cause
legacy and BC reasons preventing future improvement.

I believe the pre-requisit is having some form of function overloading,
where operator functions for specific argument types can be defined. In
https://news-web.php.net/php.internals/108425 Andrea created an idea,
which is probably "ugly" but has less usage restrictions. I think
spending time on function overloading (I believe, without proving it,
this can be done with very little cost for non-overlaoded cases - by
adding a flag "overloaded" along visibility flags and check that along
with the visibility check, only in case of an overload to the
"expensive" check, which still is cheaper done in the engine than
if/else chains in userspace) and then take up operator overloading
again, rather than this smart but limited approach. (For whoever does
that: spend time in C++ and its function resolution rules incl. ADL,
not to copy, but to learn) 

johannes

---

## #109379 — Arnold Daniels — 2020-03-28T09:22:44+00:00

URL: https://externals.io/message/109241#109379 · In reply to: #109376

>
>
> 
> > […]
>
> I consider operator overlaoding in general a good feature (while PHP's
> overload for + on arrays is weird)
>
> However I don't like this design.
>
> Consider this case: Some library provides a type A without overloads. I
> then create a type B with overload:
>
>     class B {
>         static public __add($lhs, $rhs) {
>             if ($lhs instanceof A) ...
>             elseif($rhs instanceof A) ...
>             else error
>         }
>     }
>
> as I want my type's addition to commutative I handle this with some if
> (probably dispatching. Now I can invoke it:
>
>    new A() + new B(); // calls B::__add()
>    new B() + new A(); // calls B::__add() as well
>
> Now the maintainer of A implements the feature request "A should allow
> addition with integers", I update my library and suddenly weird things
> happen.
>
>    new A() + new B(); // calls A::__add() and explodes, as A doesn't know
> B
>    new B() + new A(); // calls B::__add() works as before
>
> Now we could establish the best practice that one type's operator calls
> the other type's operator in case it can't handle a type. However that
> is no good option as it will lead to infinite recursion if neither type
> can handle both operands.
>
>
> The issue is that by forcing type declarations as part of the class, as
> members, this forms a closed set, but for many cases a strict closed
> set isn't what one wants. For mathematical types having operators
> working with integers (and other numeric values) is essential.
> Communativity often also is required.  So a true closed set doesn't
> work, for an open set can't be created easily in today's PHP. Thus the
> RFC tries to tie this together, but this will fall apart and then cause
> legacy and BC reasons preventing future improvement.
>
> I believe the pre-requisit is having some form of function overloading,
> where operator functions for specific argument types can be defined. In
> https://news-web.php.net/php.internals/108425 Andrea created an idea,
> which is probably "ugly" but has less usage restrictions. I think
> spending time on function overloading (I believe, without proving it,
> this can be done with very little cost for non-overlaoded cases - by
> adding a flag "overloaded" along visibility flags and check that along
> with the visibility check, only in case of an overload to the
> "expensive" check, which still is cheaper done in the engine than
> if/else chains in userspace) and then take up operator overloading
> again, rather than this smart but limited approach. (For whoever does
> that: spend time in C++ and its function resolution rules incl. ADL,
> not to copy, but to learn)
>
> johannes
>
> --
> 
> 
>
>
This issues become even more apparent when sequencing operations like `$a +
$b + $c - $d`. Trying left, then trying right, will make it very difficult
to determine the outcome of such a statement.

The arguments against type hinting for operator methods, assume the "try
left/right" method. Instead, type hinting should be applied to determine
which method should be used. If both or neither methods are applicable, an
error must be thrown.

With class inheritance, you also don't want to rely on the order of the
operands. If you're the creator of a library, that's out of your hands. If
both the parent and child class overwrite the operation, and both accept
the operands, then the child class should always be used.

It's a -1 for me. I would vote in favor of an RFC for operator overloading
without the "try left, try right" behavior.

Arnold

---

## #109382 — Christoph M. Becker — 2020-03-28T12:25:11+00:00

URL: https://externals.io/message/109241#109382 · In reply to: #109379

> This issues become even more apparent when sequencing operations like `$a +
> $b + $c - $d`. Trying left, then trying right, will make it very difficult
> to determine the outcome of such a statement.
>
> The arguments against type hinting for operator methods, assume the "try
> left/right" method. Instead, type hinting should be applied to determine
> which method should be used. If both or neither methods are applicable, an
> error must be thrown.

This "try left/right" approach is how operator overloading works for
internal classes[1], and apparently, it works quite well, as long as it
is not overused.

> With class inheritance, you also don't want to rely on the order of the
> operands. If you're the creator of a library, that's out of your hands. If
> both the parent and child class overwrite the operation, and both accept
> the operands, then the child class should always be used.

If a subclass overrides the operation, it would have to conform to
parameter type contravariance, so it would always be used, anyway.

[1]
<https://github.com/php/php-src/blob/php-7.4.4/Zend/zend_operators.h#L934-L937>

--
Christoph M. Becker

---

## #109384 — Andrea Faulds — 2020-03-28T13:13:52+00:00

URL: https://externals.io/message/109241#109384 · In reply to: #109352

Hi,

Michał Brzuchalski wrote:
> The first thing is for operator methods when the operation is not supported
> I would see simply `return null;` as the right solution
> instead of constant, which name no one will remember.

If we are to allow arbitrary use of operator overloading (rather than 
restricting it to specific kinds of use), which this RFC does, then IMHO 
we shouldn't special-case “null” — why can't it be a valid result of an 
overloaded operator? It is an arbitrary constraint on what can be done 
with operator overloading and makes the feature less generic.

I would prefer if we used a different mechanism, for example a special 
subclass of Exception which will be caught internally by the operator 
overloading code, so that signalling an operation is unsupported can be 
“out of band” if that makes sense.

> The second thing is notices which are confusing when suggesting to go
> and implement overloaded operator method on extension derived classes
> like stdClass like below:
> 
> Notice: You have to implement the __add function in class stdClass to use
> this operator with an object in...
> 
> The text of the notice is not documented in the RFC but it is implemented
> that way in the patch.

Please document all notices your patch produces in the RFC, I think they 
are an important detail of the proposal.

> A PHP developer is not likely gonna download the php-src source code,
> build environment and go with the ext/standard implementation and start
> adding it in C.
> The notice in this cases should either be different or not emitted at all.
> If the latter then that has to be documented I guess.

That sounds reasonable, and it should be simple to add a check to your 
patch to make sure it won't show this message for internal/extension 
classes, right? By the way, if the operation has two operands, one of 
which is an internal/extension class and the other a user class, you 
could perhaps still show the mssage, but only mention the user class name.

Regars,
Andrea

---

## #109385 — Sebastian Bergmann — 2020-03-28T13:19:59+00:00

URL: https://externals.io/message/109241#109385 · In reply to: #109376

Am 27.03.2020 um 21:10 schrieb Johannes Schlüter:
> However I don't like this design.
> [...]
Changed my vote back to "no" based on Johannes' arguments.

---

## #109387 — Andrea Faulds — 2020-03-28T13:29:56+00:00

URL: https://externals.io/message/109241#109387 · In reply to: #109382

Hi,

Christoph M. Becker wrote:
> 
> 
> > […]
> 
> This "try left/right" approach is how operator overloading works for
> internal classes[1], and apparently, it works quite well, as long as it
> is not overused.

I think “as long as it is not overused” are the key words there. We have 
a very limited number of internal classes with operator overloading 
right now, and the authors know about what other such classes exist and 
therefore can design with them in mind. But once any userland PHP class 
can use operator overloading, you could start seeing uses of operators 
where the left- and right-hand side are classes from unrelated libraries 
whose authors were not aware of eachother, and that could create strange 
problems when one or the other library is updated with operator overload 
handling.

Consider Arnold's example:

     $a + $b + $c - $d

We are not constraining operator overloading to just be for number-like 
objects, it can in principle be used for absolutely anything. $a here 
might have an overload that works for any right-hand-side object, but 
then once $b adds its own similar overload in a new version, the code no 
longer does the same thing when it's flipped around ($b + $a), violating 
the normal expectation that `+` is commutative, and that's before 
considering what $c and $d might do!

Thanks,
Andrea

---

Next page: https://externals.io/message/109241.md?page=2