Re: Revisiting Userland Operator Overloads

> On Aug 11, 2021, at 5:25 AM, Jordan LeDoux <jordan.ledoux@gmail.com> wrote: > > I want to avoid this. :) The implementations in my actual math libraries are much more thorough > and thought out. This is an example. If people want to see something that is closer to what would > actually be done in a library, they should look at an actual library. So instead, that's what > I'll link to: > > Here's the multiply method: > https://gist.github.com/JordanRL/98cceb392ba5ba943462fe574f18de51 > <https://gist.github.com/JordanRL/98cceb392ba5ba943462fe574f18de51> > Here's the translateToParts method: > https://gist.github.com/JordanRL/2c67acb3b5d3069c3a4d2f0448a480d1 > <https://gist.github.com/JordanRL/2c67acb3b5d3069c3a4d2f0448a480d1> > Here's the PolynomailFunction: > https://gist.github.com/JordanRL/673e357e7f5cf63bd4554fb3161c026b > <https://gist.github.com/JordanRL/673e357e7f5cf63bd4554fb3161c026b”W¶€šÆ˜Nÿ‡K” > Z> > > You can think of ImmutableDecimal as Real|Imaginary, but with methods such as $obj->isReal() > and $obj->isImaginary() on it. > > This is just for the __mul() method. The intent of this example is to show the nature of the > problems being solved, not to show the actual solutions. Think of this as syntactically correct > pseudo-code, not an actual implementation. Well, I refactored not to provide an actual implementation but to try to show the problems being solved in a manner that could be more easily understood. But it is your RFC, so it's yours to decide how code is presented. ---- Anyway, I'll summarize as I am going to try to wrap up my participation in this topic, at least for now: 1. I argue that it would likely be a mistake to add general purpose operator overloading to classes in PHP (or at least before a lot of experience with #2.) 2. However, I recognize there are use-cases which beg for operator overloads I think PHP. And I believe those use-cases are finite: money, the math examples, and units[1] being three (3) subsets. I think PHP would be better served by adding those use-cases as standard library classes[2] instead of adding general purpose operator overloading to the language. 3. However, *if* there is strong consensus that we should add general purpose operator overloading then I argue that it should be limited to "value" objects, which currently would mean only classes where all public and protected properties are read-only[3]. 4. And even if we do #3 that is no reason for us not to consider also doing (at least some of) #2. #fwiw -Mike [1] https://www.nist.gov/pml/weights-and-measures/metric-si/si-units <https://www.nist.gov/pml/weights-and-measures/metric-si/si-units> [2] I mean, how great would it be to have a Length class with unit conversions built into PHP? Or a Money class that all libraries that deal with Money would be able to interoperate with? Having these non-changing concepts built-in to PHP would be a strong reason developers to choose PHP over other options like Node where they have to manage tons of ever-changing and incompatible 3rd party dependencies. Better that than 10+ different userland implementations of the same bedrock concepts, many of which are incomplete and all of which are incompatible with each other. [3] Yes, private property values could be changed by methods and thus leak to the outside. But that could be considered an anti-pattern. If said private property(s) (partially) represent the state of the object and are not readonly then we could simply recognize that as an unchecked bad practice.