Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117729
MIME-Version: 1.0
References: <CAMrTa2FhEkhpDAyPR=6tt1M=F7SZRhh9RYydSO7p_Xv80X=Dfw@mail.gmail.com>
 <E21DF568-278F-43DE-9526-5CC89893D904@gmail.com>
In-Reply-To: <E21DF568-278F-43DE-9526-5CC89893D904@gmail.com>
Date: Fri, 13 May 2022 07:49:20 -0700
Message-ID: <CAMrTa2Hizwez6Eo3tQTLKB2qf3CjT-QtRbd4amnam21qb9DmmA@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000483a4005dee5c876"
Subject: Re: [PHP-DEV] The future of objects and operators
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000483a4005dee5c876
Content-Type: text/plain; charset="UTF-8"

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

--000000000000483a4005dee5c876--