On Fri, Jun 28, 2024, at 20:39, Jordan LeDoux wrote:
>
>
> On Fri, Jun 28, 2024 at 10:47 AM Rob Landers <[email protected]> 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