Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117943
Return-Path: <landers.robert@gmail.com>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 27261 invoked from network); 14 Jun 2022 12:10:11 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
  by pb1.pair.com with SMTP; 14 Jun 2022 12:10:11 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id B4A50180506
	for <internals@lists.php.net>; Tue, 14 Jun 2022 06:57:41 -0700 (PDT)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,
	RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,
	T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2
X-Spam-ASN: AS15169 209.85.128.0/17
X-Spam-Virus: No
X-Envelope-From: <landers.robert@gmail.com>
Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by php-smtp4.php.net (Postfix) with ESMTPS
	for <internals@lists.php.net>; Tue, 14 Jun 2022 06:57:41 -0700 (PDT)
Received: by mail-oi1-f174.google.com with SMTP id h187so11694290oif.4
        for <internals@lists.php.net>; Tue, 14 Jun 2022 06:57:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=tf6VSSVHQdyPeJX3f2aI8jNWN/JZiG1iG07LNft/w3M=;
        b=BYDwlSO5fRCzqjD3dyU4r4CvH0cvlceqBTL5AZhjlUMg3Pb8CpNv8EjEKp0w37UyJE
         YyRlC1pd2MSMO3cS4Z13p6XIDAq9dq0CYoGQvfQJgv8Unkd2nlJPIUr0z6WbpxMSwNee
         7ORGsYqZTO0Eufb6JfTNqO0UaB788cUqvl3cUwIX9ISdljZDOSwSCrn9FQ9jEGx/UF6P
         fKdylG7alTP7S4tAoZWC06U6ElF9Sot+td9YuYiAEYMySrgls1dASADUP1hY1gg93VSn
         G9Lkvu+CH4SVBeCy1krSZqwklm765NKtdjbzC+JSzrHb4m0wVwJA+pbJN+uOTgysVC/3
         0Ojw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=tf6VSSVHQdyPeJX3f2aI8jNWN/JZiG1iG07LNft/w3M=;
        b=IjFYuHvozbJcok+mEYwsPl4VOeabATlOT2ea/AZloi6HpJ+z27KhUXR4AwjoOrbIQw
         Oj307vSJJqE6lmrNfDsUi85pHq5n7oy7RSiovGBqAlQOYVxumLBxy/mHUfItVr0uCYD6
         hOfa+yh5pL4LqOVMcbCojH3pPVs8VakpggOk2xXMmiywXFH2ZT5DHLdZHlmPELwrk5zc
         I/pS/OUdGyVKL17vZ0tOI25tKa1f3oPulvJfam/Kd+H3Hg9PivTXdnORL2TxUb2bXgD+
         qpae03awratfaN9ANzHu7Mj1yYbUIcHvTeYjKrJwxGxIXvcChf6/h5tntVvzXXk9N81j
         RXPw==
X-Gm-Message-State: AOAM532we1JesPsbWrmvLShzGOeTn0gkvqRp4bLEvMXhKDnE1gLxPjdX
	iE+vpIfEnuG5dURgmmM6k0p2z/M4neFIjA3d0MA9zXEUt+S00w==
X-Google-Smtp-Source: ABdhPJzBx7afAJ4ot8SdN6RSM/I0ucBhzshvoMCWtMJ3/+RUxn8lRnTNGFAzjmBu2vcFAgd5nAUX15IaENoh7+FFyuo=
X-Received: by 2002:a05:6808:1905:b0:32e:c7f6:b75c with SMTP id
 bf5-20020a056808190500b0032ec7f6b75cmr2250403oib.247.1655215060674; Tue, 14
 Jun 2022 06:57:40 -0700 (PDT)
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.