Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116772
MIME-Version: 1.0
References: <CAMrTa2Emxro81j7UMA5QZ+wCOY7g46LSotLRD4oUG7HEfqSD0A@mail.gmail.com>
 <CADyq6sKP6fztfF54e_VTHJRMcB8b0_TahMTTY0hw8LAgciY61w@mail.gmail.com>
In-Reply-To: <CADyq6sKP6fztfF54e_VTHJRMcB8b0_TahMTTY0hw8LAgciY61w@mail.gmail.com>
Date: Mon, 3 Jan 2022 15:40:18 +0100
Message-ID: <CAB-BujZB31Ccw6nhN9PG1-VDqt8YkijsYUBYPxJ-Ss1Ng4KJ+w@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: Jordan LeDoux <jordan.ledoux@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [VOTE] User Defined Operator Overloads
From: andreas@dqxtech.net (Andreas Hennings)

On Mon, 3 Jan 2022 at 02:07, Marco Pivetta <ocramius@gmail.com> wrote:
>
> Hey Jordan,
>
> I've voted "no" on this one: infix functions may have been interesting, but
> adding a whole new type system around operators is really not worth it,
> given:
>
>  * Added AST nodes
>  * Added method definitions for niche use-cases
>  * Complexity in support for static analysis tools
>
> I personally don't see a reason to introduce all this for examples like the
> one with GMP, which was more readable before adopting userland custom
> operators.
>
> In addition to all that, we didn't even achieve custom operators anyway:
> it's just the built-in ones (this is why I mentioned infix functions), and
> the precedence, number and type of operands are fixed too (yes, it is a
> sensible starting choice, but very little "custom" about it).
>
> Overall, your RFC is exactly what I would expect a custom operator RFC for
> PHP to look like: I just don't think the feature is needed at all, as it
> only makes the language much more complex, for rare cases that I hope I
> will never ever have to debug in future.

Perhaps we need more discussion about use cases to justify this RFC?

I think the main use cases mentioned so far were for arithmetic
operations between value objects that represent money, time, or other
measurable values, or mathematical higher-order values (vectors etc).

I imagine that operator overloads can improve DX for these use cases,
but at a cost for the overall language.

How would you (Marco) see the future of arithmetic libraries for time,
money etc without overloaded operators?
How would these calculations look like e.g. with infix functions?
Do you think this can eliminate the desire for operator overloads?

E.g. something like this?

$ts0 = new Timestamp($seconds0);
$ts1 = new Timestamp($seconds1);
/** @var Duration $duration */
$duration = $ts1 - $ts0;  // Operator overload notation.
$duration = Duration::betweenTimestamps($ts0, $ts1);  // Static method notation.
$duration = $ts1->diff($ts0);  // Object method notation.
$duration = $ts0 <Duration::betweenTimestamps> $ts1  // Infix notation
based on static method.
$duration = $ts1 <diff> $ts0  // Infix notation based on object method.

I generally like names I can click on, if they don't get too long..
I like if the choice of implementation is knowable by just looking at the code.
(with a small range of runtime polymorphism)
I like if some functionality is implemented outside of object methods,
keeping interfaces and inheritance chains simple.

But for code with lots of calculations, a simple "-" feels simpler and
more explanatory than something like "diff" or "timediff", where I
have to reference and remember a specific method/function name.

-- Andreas


> Greets,
>
> Marco