[RFC] Userspace operator overloading

On 15/02/2020 22:05, jan.h.boehmer@gmx.de wrote:

"If an operator is used with an object that does not overload this operator, an NOTICE is triggered, which gives the user a hint about the method that has to be overloaded. For backward compatibility objects, which do not overload the operator, are converted to integer 1 (current behavior)." Noooo :( Notices are the enemy of all that is great and good. If operator overloading is going to become a first-class feature then it should be treated as such, and attempting overloading operators on objects that don't have the relevant method available should trigger an Error.

On 15 February 2020 22:05:52 GMT+00:00, jan.h.boehmer@gmx.de wrote:

As I mentioned earlier [1] I think the answers to both of these questions depend on a fundamental philosophical question about what you're overloading: - The groups of operations which exist for built-in types e.g. the arithmetic operations overloaded by GMP; or string operations overloaded by an object with enhanced Unicode functionality. - The individual symbolic operators, with no intrinsic meaning - e.g. overloading . for concatenation on strings but dot-product for vectors; or a DSL overloading << and >> for "into" and "out of". I think it would benefit the RFC to take a stance on that question, and build the feature around it. [1] https://news-web.php.net/php.internals/108347

On Sat, 15 Feb 2020 at 23:06, <jan.h.boehmer@gmx.de> wrote:

Just as a FYI, I'll vote No to this RFC regardless of arguments as I find operator (and method) overloading a bad idea in general. Moreover, the only ones I am a tiny bit less reluctant to overload are the mathematical operators. However, one of the major reasons to want to have this seems to add better support for Matrices and Complex number which can already be done at the extension/engine level. Best regards George P. Banyard

jan.h.boehmer@gmx.de wrote:

I very much appreciate this initiative, as well as that of Patricio/Sara, and I agree with what people have said about the importance of realistic use-cases for something like this. Our company produces ads, and the price calculation is quite complex, involving the size of the ads, various discounts, etc. We're using objects for these calculations, to ensure we don't mix up units. Here are some examples: $price_per_column_mm = new PricePerColumnMm(1234); // Price = 1234 * number of columns * height in mm $height = new LengthInMm(100); $price_per_column = $price_per_column_mm->multiply($height); // Returns a PricePerColumn object $columns = new Column(4); $price = $price_per_column->multiply($columns); // Returns a Money object It gets more complicated, when we add in discounts: $discount_percentage = new Percentage(10); $end_user_price = $price->subtract($discount_percentage); // Price = Price * (100-discount percentage)/100 These are just a few examples, but it shows the advantage of using strongly typed objects in expressions, so that we don't do nonsensical things like multiplying two Money objects, or try to use a PricePerColumn object as a Money object. As you can probably tell, having all those "add", "subtract", "multiply", etc. method calls makes it hard to understand what is going on, and even if things happen in the right order, because when you use method calls, you can't change the order of execution without breaking an expression up into multiple expressions: It always happens from left to right. In order to support code like the above, we'd need to be able to define the following operators: PricePerColumnMm * LengthInMm -> PricePerColumn PricePerColumn * Column -> Money Money - Percentage -> Money This comes in addition to the usual operators that takes the same type on both sides, such as Money + Money, etc. Please note the last one, which is a non-commutative operation (Money - Percentage != Percentage - Money), which wouldn't work in Patricio's proposal, unless the "Associativity" section is rewritten to handle this in a different way. I like Patricio's proposal in that it uses ordinary, non-static methods, but unfortunately, it then runs into this problem, which seems to favour Jan's proposal. With regard to the mechanism for handling this (interfaces, magic methods, or a magic __overload() method), or Sara's proposal for registering overloads, using overload_type(), none of that are deal-breakers for me. Still, as we already have "magic methods" for other things (and interfaces, yes, I know), I'd lean towards implementing these as magic methods, which lets a developer only implement the operations that makes sense in their domain. Also, I think we should distinguish between non-assign and assign operators, giving them different method names, because some types may be expensive to copy, for example a large matrix, so $matrix *= $vector could be way more efficient than $matrix = $matrix * $vector. Regards, Terje