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
