Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125517
Message-ID: <23a8ceb3-53e8-4c88-b728-a31212db447e@gmx.de>
Date: Thu, 12 Sep 2024 01:30:23 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Zephir, and other tangents
Content-Language: de-DE
To: Hammed Ajao <hamiegold@gmail.com>, Mike Schinkel <mike@newclarity.net>
Cc: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, internals@lists.php.net
References: <A247BB36-9FD1-4AAF-AAB8-82DBD9DE3550@newclarity.net>
 <CA697780-BC2D-4054-A9FD-523E08236732@rwec.co.uk>
 <8D420123-4ECF-48FD-A9C3-F80C60457A37@newclarity.net>
 <CA+Jpajkx0OraH7GQyB5gECtPOo2JP=RzuSwqfv4AZGY+a+ryPw@mail.gmail.com>
In-Reply-To: <CA+Jpajkx0OraH7GQyB5gECtPOo2JP=RzuSwqfv4AZGY+a+ryPw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:3PfsjeEtfME=;CpAffU4Jq09e1XEj9oUe/TwUgro
 zC5YjDLPLlCmAzz2mRItmu3Q6QT2VUSxEB7nbwrTw46a73hLyIlw4jWzU5E7P41soCkO6GqFz
 UqTlJuU3BsYf6rKPTxelV+PWLqlpJ1TprKibT9JIVDMts6IEXZExhV6MhOTTRSG4fWio04DjT
 lYQB0QVZZSzFoMzRmoM6BM32BFsbav8jPizgw0U8AVih7U9QFQu/Cl+ICuG+fl9oGP5GUCpxu
 ylhxcXFoMtN2g4bMLHGc5b3fwl20+Qj2J7H6gZfLttAoGGFMu0qRdlbQGadeqW2hrZGCQ8NLK
 R6d0DInLgHZU3+BK47ji2shaqirYBXKLaVMzBdm+HDbXgE2ezId0JCpTQmBLsnpUvE11UwNh3
 JdokmcIMGdFGJ7rvs2gRPylH7GYfcQIMiSosrgsDGIkNWJ/FBaUFJFXsqJ/1t8uVgNwAPpAYu
 lLp6dViBz9Ag65UWi11kjGZJ88TziZfBX8HYj7StwTPA4y5dKI6ny78rpR6Um9q+bS8766EYR
 ZV8VENbhwZUkeUNTHOIiHU5YfvJfyndjpd5oYoju2VX2kvzZqu4EBq9vLp925vetK7wfaj6bu
 FM+3hIUYBksgi6q7BI+n2CGFcs2BtBYsksZ7iHmYETF2lskLq4DkPdfayHepFDVUbkNJUxlSE
 zmhO+a0BBFiVJafJLswu6eb1rmOqV/bJvfu0Kp3W8ac0U6DuiEd0J7T26nbrL3CNe3gtq6Og+
 gNR98v0QGij7PCC/tNRmqjtMFExYcHhUwz/mkaL7Jnmn7+3jsAsJLWk2T+/6ssJPQiJbVGa3p
 7Kxq3fJqRi5EMC2Jkti2EPqExGrUvbZfsIViRlt16BDWQ=
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 11.09.2024 at 22:43, Hammed Ajao wrote:

> Your point about operator overloading doesn't seem valid either. Conside=
r
> the following:
>
> ```php
> class X {
>     public function plus(X $that) {}
>     public function equals(X $that) {}
> }
> ```
>
> In this case, `plus` could represent any behavior, as could `equals`. If=
 I
> wanted to, I could implement `plus` to perform what `equals` does and vi=
ce
> versa. Should we consider methods broken just because their names can be
> arbitrary?
>
> PHP already distinguishes between comparison operators for objects:
>
> ```php
> <?php
> $obj1 =3D $obj2 =3D new stdclass;
> assert($obj1 =3D=3D=3D $obj2); // compares object IDs
> assert($obj1 =3D=3D $obj2);  // compares properties
> $obj1 =3D new stdclass;
> assert($obj1 !=3D=3D $obj2);
> assert($obj1 =3D=3D $obj2);
> ```
>
> `=3D=3D=3D` compares object IDs, while `=3D=3D` compares their propertie=
s. Beyond
> this, there's little reason to apply an operator to an object directly. =
Why
> would you need to call `$user1 + $user2` or similar operations on an
> object? What scenario would break by allowing operator overloads?
>
> However, consider a case where comparing just one property of an object
> (like a hash) is enough to determine equality. Wouldn't it be great if,
> without changing any of the calling code, the engine compared `$this->ha=
sh
> =3D=3D=3D $that->hash` when `$this =3D=3D $that` is invoked, instead of =
all
> properties? Without operator overloading, I'd have to define an `equals`
> method and replace every `$obj =3D=3D $x` call with `$obj->equals($x)`.
>
> Moreover, operator overloading unlocks new possibilities for algorithm
> design. For example, you could define complex mathematical operations on
> custom objects, enabling you to express algorithms more concisely and
> naturally. Imagine implementing vector addition, matrix multiplication, =
or
> symbolic computation directly in PHP. Instead of verbose method calls li=
ke
> `$vec1->add($vec2)` or `$matrix1->multiply($matrix2)`, you could use sim=
ple
> and intuitive syntax like `$vec1 + $vec2` or `$matrix1 * $matrix2`. This=
 is
> particularly useful for domain-specific algorithms where overloading
> enhances readability and performance.
>
> Operator overloading isn't just about convenience. It opens the door to
> more expressive algorithms, better readability, and reduces boilerplate
> code, all while maintaining backward compatibility with existing PHP
> behavior.

I fully agree, but note that at least two RFCs regarding userland
operator overloading have been declined[1][2], and from what I remember
at least partially because the feature could be "misused".

[1] <https://wiki.php.net/rfc/user_defined_operator_overloads>
[2] <https://wiki.php.net/rfc/userspace_operator_overloading>

Christoph