Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108301
MIME-Version: 1.0
References: <00ea01d5d630$b18d4f20$14a7ed60$@gmx.de>
In-Reply-To: <00ea01d5d630$b18d4f20$14a7ed60$@gmx.de>
Date: Tue, 28 Jan 2020 20:33:21 -0300
Message-ID: <CAEsg9X1HvPsPQXuY+rceuX159uOeK44X-qkPX-rvDRuMnu-UvQ@mail.gmail.com>
To: jan.h.boehmer@gmx.de
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f9b276059d3ba6f8"
Subject: Re: [PHP-DEV] Operator overloading for userspace objects
From: david.proweb@gmail.com (David Rodrigues)

--000000000000f9b276059d3ba6f8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 =C3=A0s 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 so=
me
> problems, when implementing the operator functions as (non-static) class
> members and pass them only the =E2=80=9Cother=E2=80=9D argument: What hap=
pens 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 A*B =3D/=3D B*A). 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 i=
t
> 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 operatio=
n
> (like Python does), because I think that way it is the clearest way to se=
e,
> 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 discussi=
on
> 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). Thi=
s
> would lead to either that only parts of the interfaces are implemented (a=
nd
> the other just throw exceptions) or that the interfaces contain only one =
or
> two functions (so we would have many interfaces instead of magic function=
s
> in the end).
>
>
>
> On the topic which operators should be overloadable: My PoC-implementatio=
n
> 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 (<, >, <=3D, >=3D, =3D=3D) are eval=
uated. I
> think this way we can enforce, that the assumed standard logic (e.g
> !($a<$b)=3D($a>=3D$b) and ($a<$b)=3D($b>$a)) of comparison is implemented=
. Also I
> don=E2=80=99t think this would restrict real world applications much (if =
you have
> an
> example, where a separate definition of < and >=3D could be useful, pleas=
e
> comment it).
>
> Unlike the original idea, I don=E2=80=99t think it should be possible to =
overwrite
> identity operator (=3D=3D=3D), because it should always be possible to ch=
eck 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 +=3D, -=3D the situation is a=
 bit
> more complicated: On the one hand the user has learned that $a+=3D1 is ju=
st
> an
> abbreviation of $=3D$a+1, so this logic should apply to overloaded operat=
ors
> as well (in C# it is implemented like this). On the other hand it could b=
e
> useful to differentiate between the two cases, so you can mutate the obje=
ct
> itself (in the +=3D 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=E2=80=99t think that this would be a big proble=
m, so my
> PoC-Code does not provide a possibility to override the short hand
> operators.) For the increment/decrement operators ($a++) it is similar, i=
t
> would be nice if it would be possible to overload this operator but on th=
e
> other hand the use cases of this operator is really limited besides integ=
er
> 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 th=
e
> normal priority (defined by PHP), my code checks if the element on the le=
ft
> 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 clas=
s
> 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=E2=80=99t 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=C3=B6hmer
>
>
>
>

--000000000000f9b276059d3ba6f8--