On Fri, May 13, 2022 at 4:49 PM Jordan LeDoux <jordan.led...@gmail.com> wrote:
>
> On Fri, May 13, 2022 at 7:05 AM Rowan Tommins <rowan.coll...@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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
