On Sat, Aug 7, 2021 at 8:26 PM Dusk <d...@woofle.net> wrote:
> On Aug 7, 2021, at 15:28, Larry Garfield <la...@garfieldtech.com> wrote:
> > As an example here, time units. Adding two hour:minute time tuples
> together to get a new time (wrapping at the 24 hour mark) is an entirely
> reasonable thing to do. But multiplication and division on time doesn't
> make any sense at all. Or, maybe it does but only with ints (2:30 * 3 =
> 7:30?), kind of, but certainly not on the same type.
>
> This touches on another important question -- how do we plan to represent:
>
> 1) An operator which is only applicable when an operator is used on two
> dissimilar types (e.g. TimeTuple x float)?
>
> 2) An operator which can be applied to an object, but with a primitive or
> otherwise non-extensible type on the left hand side of the operator (e.g.
> float x TimeTuple)?
>
> 3) An operator which can be used with multiple types, but whose meaning
> and/or return value can change based on what types are used (e.g. Matrix x
> Matrix vs. float x Matrix)?
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
The short answer is that all three of these concerns *must* be left up to
the userland implementations. Our job, realistically, should be to provide
a sane and consistent way for their implementations to accomplish this. But
truly, for most of these conditions the interpreter can't make enough
assumptions about the purpose to make any meaningful contribution on
questions like these.
Because of this, as far as actual implementation goes, I was gravitating
towards one of two possible formats:
function __op($rhs) {
} // Binary operators
function __op() {
} // Unary operators
In this implementation, an object could *only* overload the operator if it
was on the left hand side. There are some advantages to this. It simplifies
the cases within the do_operation function that would need to be considered
for instance.
function __op($pos, $lhs, $rhs) {
} // Binary operators
function __op() {
} // Unary operators
In this implementation, the $pos argument would be 0 if the called object
was on the left, and 1 if the called object was on the right. The right
hand side would obviously not be passed for unary operations (though there
aren't any unary operations that I plan to implement in this RFC). The
major advantage of this implementation is that the code which is most aware
of the context and meaning could fully handle the situation, regardless of
whether the object was on the left or right. This would allow us to provide
something that is *more* commutative, even if full commutativity isn't
desirable for the reasons I've outlined earlier.
Jordan
