Re: [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Mon, Sep 16, 2024, at 2:47 AM, Jordan LeDoux wrote: > On Sun, Sep 15, 2024 at 9:12 PM Larry Garfield <larry@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