[VOTE] Userspace operator overloading View as Markdown

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.

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/

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

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

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.

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
^^^^^^^^^
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

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

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

--

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

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.

Hi Johannes,

Johannes Schlüter wrote:

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)

Thinking about what I suggested there again now, I think it's a shame
this RFC includes the following restriction:

The argument must not specify any argument typehints (an error is
thrown otherwise), as typehints and occuring type errors would break
operator evaluation (see discussion).

With strict evaluation of union types, it would be possible to achieve
something like what I suggested in a less ugly form:

 class A {
     /* … */
     public function __add(int|float|B $other) {
         /* … */
     }
 }
 class B {
     /* … */
     public function __add(int|C $other) {
         /* … */
     }
 }

From the union typs in this example, the interpreter could see, without
having to execute either overloaded method, that A provides an overload
for B, int and float, and B provides an overload for C and int, and so
it knows the same method can be called for both $a + $b and $b + $a,
likewise for $b + $c and $c + $b.

Of course, this requires interpreting type declarations in an unusual
way, and it also needs a solution to non-commutative operators (perhaps
a second parameter that would contain a boolean specifying whether
$this is on the left), but I think it is less likely to be chaotic
than the current proposal.

Thanks,
Andrea