Re: Revisiting Userland Operator Overloads

On Tue, Aug 10, 2021, at 1:51 AM, Mike Schinkel wrote: > 2.) Then I thought: What if PHP had the ability to explicitly define > *value* objects? I know this has been something Larry Garfield has > mentioned[1] in the past. > > What if we had a new type of class that is to be used only for value > objects. Following Larry's lead they would be immutable. And if we had > those then I think adding generic operators overloading to value > objects would make a hell of a lot of sense. Maybe: > > #[\PHP\Value] > class ComplexNumber{} > > Or: > > class ComplexNumber value{} > > Or: > > ??? > > Can you see any reason why only allowing the addition of operator > overloads to *value* objects would too limiting? > > IMO that would minimize the abuse potential for implementing operators > as a leaky abstraction when developers are ignorant of the > ramifications and/or are more concerning about their convenience than > longer term maintainability. > > [1] https://twitter.com/Crell/status/621715583403487232 Point of order: I do not support a dedicated value-object/data-object construct, and have said so explicitly. I support targeted tools that make using objects in that fashion cleaner and more robust. (readonly, asymmetric visibility, clone-with, etc.) Please do not misrepresent my position, especially when I've been fairly consistent on it. Also, one of the biggest failings of SPL is the degree to which it leverages and forces extension rather than interfaces. Inheritance is a code reuse tool, NOT an architecture tool. That's what interfaces are for. We know this. We've been bitten by this. Building any kind of inheritance-based operator overloading into the language would be a terrible idea. Let us never speak of it again. --Larry Garfield