On 15/02/2020 22:05, jan.h.boehmer@gmx.de wrote:
How many of you would prefer a interface solution for operator
overloading?
I wonder if the RFC voting should include the option to choose between
either the magic method approach (with the syntax proposed in the
current
RFC version) or using interfaces.
For an interface version I would suggest these interfaces:
ArithmeticOperators (implements +, -, *, /), PowOperator (**),
ModuloOperator (%), ConcatOperator (.) and BitwiseOperators (~, &, |,
^, <<, >>> ).
+1 for magic methods.
There's too many domains where only a few of the operators makes sense and groupings like ArithmeticOperators would not make sense, not at least one of the motivating examples of this proposal: Being able to write a Money class and associated functionality.
Adding and subtracting money makes sense, but it makes no sense to multiply or divide them, and this is just *one* domain.
Please, let's not go there and artificially limit the possibilities of future developers.
For example, for me, it's quite natural to be able to write code like this:
$total_discount = $total * $discount;
Here, $total_discount and $total is Money, while $discount is a Percentage, so we should be able to define a method that allows you to multiply Money with Percentage, and return a Money object. Adding Money and Percentage would make no sense, but multiplying them does.
Regards,
Terje