On 11.09.2024 at 22:43, Hammed Ajao wrote:
> Your point about operator overloading doesn't seem valid either. Consider
> 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
> vice
> versa. Should we consider methods broken just because their names can be
> arbitrary?
>
> PHP already distinguishes between comparison operators for objects:
>
> ```php
> <?php
> $obj1 = $obj2 = new stdclass;
> assert($obj1 === $obj2); // compares object IDs
> assert($obj1 == $obj2); // compares properties
> $obj1 = new stdclass;
> assert($obj1 !== $obj2);
> assert($obj1 == $obj2);
> ```
>
> === compares object IDs, while == compares their properties. 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->hash
> === $that->hash when $this == $that` is invoked, instead of all
> properties? Without operator overloading, I'd have to define an equals
> method and replace every $obj == $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 like
> $vec1->add($vec2) or $matrix1->multiply($matrix2), you could
> use simple
> 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