Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117943
MIME-Version: 1.0
References: <CAMrTa2FhEkhpDAyPR=6tt1M=F7SZRhh9RYydSO7p_Xv80X=Dfw@mail.gmail.com>
 <E21DF568-278F-43DE-9526-5CC89893D904@gmail.com> <CAMrTa2Hizwez6Eo3tQTLKB2qf3CjT-QtRbd4amnam21qb9DmmA@mail.gmail.com>
In-Reply-To: <CAMrTa2Hizwez6Eo3tQTLKB2qf3CjT-QtRbd4amnam21qb9DmmA@mail.gmail.com>
Date: Tue, 14 Jun 2022 15:57:28 +0200
Message-ID: <CAPzBOBO1TWTVqJP_p76qhN8o-BU4-N6ndxaBGfxpFA6aGhxaig@mail.gmail.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Cc: Rowan Tommins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] The future of objects and operators
From: landers.robert@gmail.com (Robert Landers)

On Fri, May 13, 2022 at 4:49 PM Jordan LeDoux <jordan.ledoux@gmail.com> wrote:
>
> On Fri, May 13, 2022 at 7:05 AM Rowan Tommins <rowan.collins@gmail.com>
> wrote:
>
> >
> > I like Larry's "4 levels", but I've been thinking that there's some
> > existing functionality in PHP which takes a different direction: rather
> > than overloading *operators*, the language lets you overload *behaviour*.
> > We have magic methods like __get and __call, and interfaces like Iterator,
> > Countable, and ArrayAccess. Some hook into a particular function, or even
> > operator, but they're generally described in terms of what they do, not
> > what they look like, if you see what I mean.
> >
> > From that point of view, overloading comparison and equality *behaviour*
> > makes sense - it could affect not just the == and <=> operators, but things
> > like in_array() and sort(). I think this distinction is more pronounced in
> > PHP than some languages, because the standard library isn't "self-hosted":
> > a sort() call doesn't literally compile to a call to $a <=> $b
> >
> >
> I have been thinking about something similar, but not in the context of
> making operator overloads more like behavior overloads. Rather, I've been
> considering the idea that operator overloads are a *subset* of *engine
> overloads*. Ways that the developer can provide additional details to the
> engine about the behavior of their code that allows the engine to make more
> concrete assumptions about how it should be processed and interpreted.
>
> I started thinking about this mainly from the perspective of the syntax. I
> proposed the `operator +()` syntax in my overloads RFC, but my most
> compelling argument about the reason for it was sort of obscured because it
> was wrapped up in only overloads. To that end, I was considering more
> broadly what *all* magic methods are on objects: handlers. In fact, in the
> Zend engine that's how many of the same sorts of behaviors are described,
> as object handlers.
>
> Most of the standard library functions don't make calls for such handlers.
> For instance, sort() makes a call to zend_compare, and zend_compare ends up
> making a call to the compare handler on the relevant object. So I was at
> least considering the idea of a more broad replacement of the syntax for
> object behaviors, just not for an RFC related to overloads... such an RFC
> would have its own difficulties and controversy, and would almost certainly
> require a period of dual syntax support for old magic method syntax, making
> the arguments against very easy while the benefits would be more long term
> and less immediately apparent.
>
>
> > It's less obvious how that applies to mathematical operators - should
> > implementing "addition" allow an object to be used with array_sum()
> > perhaps? And what about deriving one operation from another, e.g. $foo*3
> > running $foo+$foo+$foo, or $foo**3 running $foo*$foo*$foo?
> >
> > I don't really have a conclusion here, I just wanted to throw it out there
> > as a different mental model to consider.
> >
> >
> This would only be true for numerics, but not other kinds of math, such as
> matrices. Mathematical operators really are something that require direct
> calls and direct overloads if they are supported in any way, unless the
> language is willing to essentially never have things like complex numbers,
> matrices, etc. even in extensions.
>
> Still, it's an interesting thought and definitely the kind of high-level
> discussion I was looking for.
>
> Jordan

Sorry to resurrect an old conversation, but today I'm doing some
complex/big-number math (with a compatibility layer around GMP) in
PHP, and it made me realize how much I'd appreciate at least some
operator support in PHP.

Current code:

function modNear(BN $a, BN $b): BN {
    $res = $a->mod($b);
    if($res->gt($b->shrn(1))) {
        return $res->sub($b);
    }
    return $res;
}

Desired code:

function modNear(BN $a, BN $b): BN {
    $res = $a % $b;
    if($res > ($b >> 1)) {
        return $res - $b;
    }
    return $res;
}

The latter is much easier to grok at a glance.