On 15/02/2020 22:05, jan.h.boeh...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
