On Sun, Aug 24, 2025, at 9:41 AM, Kyle Katarn wrote: >>> (No need to change it in this RFC, just note explicitly that the expected >>> behavior is identical to that min(max()) construct, regardless of type.) >>> >>> --Larry Garfield >>> >> >> It only compares the first property, and if there is a conflict, it moves on >> to the next property. That is why some of us have been advocating for >> operator overrides: because this default isn’t always appropriate, as your >> Point example illustrates. In some cases, you would want to compare >> magnitude or something else entirely, not just the x value. >> >> What is even trickier is that this process completely ignores computed >> hooks. So, if you add a hook as the first property (for example, returning >> the magnitude), it is simply ignored. As a weird side note: if you cast the >> object to an array, the computed hook disappears, but if you use >> `json_encode()`, the computed value is included. >> >> To complicate things further, the current behaviour for objects is actually >> “undefined” and it isn’t documented. There are examples that show how >> objects are compared, but they don’t explicitly mention that the object is >> being cast to an array (see the above paragraph on why that matters). >> Because this relies on implementation details rather than documented >> behaviour, it could change between PHP versions without an RFC. That makes >> relying on it a bit risky. >> >> Adding operator overrides would help by making this behaviour explicit and >> consistent across versions, or just defining it in general. But whenever >> someone tries to define this more clearly (as I started to do with Records), >> it tends to run into resistance on this list for reasons I’ve never quite >> understood. >> >> — Rob > > I would not be against operator overrides, though it starts becoming > quite complex when dealing with comparing 2 objects of different > classes. Anyway I will add a note on the RFC about objects to warn > about unexpected behavior, but this is probably out of scope, the same > concerns apply to min() and max() and that's why I added the same > warning in the documentation: "Be careful when passing arguments of > different types because clamp can produce unpredictable results." > Adding a specific note about objects in the documentation could make > sense. Then it would probably be nice if it were also added to min() > and max().
Overrides are their own complex beast, not to be tackled here. Just making sure the RFC is explicit about comparison behavior (and that it's weird in the same ways PHP is already weird) is sufficient. --Larry Garfield
