On Mon, Sep 16, 2024, at 2:47 AM, Jordan LeDoux wrote: > On Sun, Sep 15, 2024 at 9:12 PM Larry Garfield <la...@garfieldtech.com> wrote: >> >> The "multiply by -1 for <=>" bit I don't fully understand the point of. The >> RFC tries to explain, but I don't quite grok it. >> > > I will perhaps respond with more detail to the rest of your message > later, but I wanted to address this specifically, because I also feel > that the original RFC I wrote didn't explain that well. The situation > this bit was referring to is as follows: > > You have an object Foo that implements an overload for the `<=>` > operator. The proposed signature for `<=>` was simply: > > `operator <=>($other): int` > > This operator did not have an `OperandPosition` argument. The reason > for this was to prevent developers from creating situations where `5 > > $foo` is true and `5 < $foo` is true. Instead, internally it did the > same sort of reordering that the engine currently does. It calls the > implementation the developer defined, and then checks if the object > that the implementation was called from was on the right side of the > operator. If it was, then it multiplies the result of the user defined > overload by -1. Multiplying the result of the overload ONLY when the > overload is called for the right side is equivalent to flipping the > order. So `5 > $foo` is multiplied by -1 and then evaluated as if it > were `$foo < 5`. This is an edge case, but it was an important one in > my mind. > > It would be entirely unnecessary if we allowed the `<=>` overload to > know what position it was in, but that would enable lots of developer > mistakes in my mind for no real gain. Instead, developers should just > implement the overload as if the object assumes it will always be > called from the left side of the comparison. > > Jordan
OK, that makes a lot more sense. Reading through the text of the RFC, I didn't catch that it only multiplied by -1 if the comparing object was on the right. The implementation is fine, but if you do for a second round, making that a bit clearer would be helpful. --Larry Garfield
