Re: Revisiting Userland Operator Overloads

> On Aug 10, 2021, at 10:22 AM, Larry Garfield <larry@garfieldtech.com> wrote: > > 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. Seems that you have chosen to callout a distinction and take offense to[*] that I was never intending. When I referenced value objects the *how* was not the important part of my discussion but instead that fact that we do get there, evidenced by my use of "Or ???" when hypothesizing. If the way PHP gets there is that a value object is an object where all non-private properties are explicitly declared readonly then that is as workable as if we explicitly define the class with a "value" keyword. I don't really care as I see it as a distinction without a difference. Either way if PHP can identify a value object then it could limit operator overloads to just classes that are value objects by whatever approach PHP chooses to distinguish. -Mike [*] Ironically I mentioned you because I thought you would be appreciate seeing another reason PHP could benefit from value objects. But as they say, no good deeds go unpunished.