On Fri, Jun 28, 2024, at 20:39, Jordan LeDoux wrote: > > > On Fri, Jun 28, 2024 at 10:47 AM Rob Landers <rob@bottled.codes> wrote: >> __ >> Hello internals, >> >> I'd like to introduce a new RFC: >> https://wiki.php.net/rfc/operator_overrides_lite which extends the GMP >> extension to support a limited set of operator overriding to developers. >> It's designed to be limited and relatively simple, while still being quite >> powerful. It would only be available if you have the GMP extension installed >> and enabled, but would allow for creating powerful unit libraries (such as >> representing money, duration, etc). >> >> I'm very interested in your feedback! >> >> This was initiated from a discussion in another thread: >> https://externals.io/message/123872 >> >> Thanks for your time, >> >> Rob Landers > > You probably have not actually looked at implementing this yet, so let me > give you some advice: > > 1. You probably are not yet aware that operands get reordered, or their > ordering is not guaranteed, when a comparison occurs. This is because there > is no op code (currently) for Greater Than or Greater Than Or Equal. Instead > the comparison is reordered so that the operands are swapped and a Less Than > or a Less Than Or Equal is performed. This is perfectly acceptable until you > need to determine whether the left or right operand's function needs to be > called, such as with objects.
I actually did know that from implementing something like this for a client. That is why I chose “comparable” to let the developer decide if two objects are comparable or not. For example, money probably can’t be equal, less than, or more than a plain number, distance, or time. All objects must be comparable for the comparison to succeed. I have updated the RFC. > 2. The fact that the signature uses `mixed` for the typing removes a lot of > the safety features the previous RFC had, and makes a lot of the concerns > that stopped that RFC worse. In PHP currently, an object used with any > non-comparison operand results in a TypeError. In the previous proposal, this > behavior was preserved *even for objects which implement overloads* unless > they specifically listed the type as accepted in the overload definition. > What this did is ensure that anything OTHER than a TypeError guaranteed the > developer that they were dealing with an operator overload that they could go > inspect. The mixed type is on purpose until I have an implementation. I haven’t decided if both will always be a \GMP object or if float|int|string might get thrown in there too. I want the former, but I’ll have to see what I can do. I’ll have to look into that exception handling, but I don’t want to break the current behavior of GMP or make any big changes to support this. > 3. The private/protected distinction is fairly meaningless for the functions > that implement overloads, because the privacy of the function is ignored > completely when it is executed to evaluate an operator. Hmm. I like the idea of protected, because it gives a structure to it that is apparent and usable right from the IDE. You just “fill in the blanks” or stick with the default behavior. > 4. The `static` distinction is also fairly meaningless, as in PHP there is no > situation possible where an operator overload can occur WITHOUT it operating > on objects themselves. For this, that is the wrong approach. The actual behavior is on the type, not the instance. The object instances may not even know their value, they merely represent the value. > 5. Your voting choices actually constitute something that is not allowed for > RFCs. A 'yes' vote allows operator overloads for GMP, a 'no' vote changes GMP > to `final`. There is no option here to leave PHP as it currently is, which is > what a 'no' vote should mean. Yeah. I was actually wondering about this… I believe Gina made it kinda clear that it was accidentally non-final. So I was just saving everyone an RFC — maybe I will make it a secondary vote for the case where the RFC is declined. I’ve now updated the RFC. > 6. The `comparable` function you propose doesn't actually have an operator it > corresponds to. There is no operator in PHP for "is the left value comparable > with the right value". There are operators for comparisons themselves, which > I assume you meant, but a bool is insufficient as a return type for that. In the engine, there’s just a compare function for internal overrides. So we just check that everyone agrees that the two objects are comparable and then pass it on to “business as usual.” > > There's probably more, but this is a start for you to make some improvements > and changes. However, I had to warn you before you put in too much effort > that I am fairly certain this RFC has very nearly zero chance of passing. > > Jordan I have absolutely zero faith this will pass, but I will give it a fair shot. It’s the least I can do. — Rob
