Re: Revisiting Userland Operator Overloads

On 08/08/2021 08:41, Jordan LeDoux wrote:

Off the top of my head here are some of the use cases that I think benefit greatly from this: - Complex number objects - Fractions objects - Matrix objects (math) - Vector objects (math) - Time/Date intervals - Collections - Arbitrary precision numbers (which are usually represented as a string in PHP)

I think that although mathematical libraries feel like a natural example, they're actually rather a small niche in the world of PHP, so not a great advert for the feature. Collections are not necessarily a great example either, since defining "+" to mean "combine these two collections in some type-specific way" is the kind of broad overloading which is often controversial. An example which I think would be applicable to many more PHP users is a "Money" type, with a value, a currency, and perhaps a precision. It's also an interesting example where all the mathematical operators can be implemented, but restricted to certain combinations of types, and even combinations of values. A real-life example from a C# project has the following overloads (syntax tweaked to be more PHP-like): public static operator - (Money $m1, Money $m2): Money public static operator + (Money $m1, Money $m2): Money public static operator / (Money $money, float $divisor): Money // fraction of a Money value public static operator / (Money $m1, Money $m2): float // ratio of two Money values public static operator * (Money $money, float $multiple): Money // note [Money * Money] is not defined public static operator < (Money $m1, Money $m2): bool public static operator > (Money $m1, Money $m2): bool public static operator == (Money $m1, Money $m2): bool public static operator != (Money $m1, Money $m2): bool // defined as !($m1 == $m2) All operators which take two Money values throw an exception if they have different currencies. The [float * Money] case isn't overloaded here, although it would make sense; I don't know if that's because it can't be in C#'s overload system, or just that it is missing from this implementation. Since even a single operator interface can't guarantee that all inputs will have a valid output, I remain unconvinced that implementing 8 different interfaces for the above is any better than implementing one interface and stubbing the parts that have no valid inputs. Regards, -- Rowan Tommins [IMSoP]