Hi Jan,
jan.h.boeh...@gmx.de wrote:
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 (~, &, |, ^, <<,
).
I have probably already said this on this list; I like the idea of
interfaces as they discourage abuse. I'm not sure if I like those
particular groupings however:
* For integer-like types maybe supporting + - * without / would make
sense, since / is de-facto floating-point division right now
* Maybe / and ** should be grouped?
* It's a shame intdiv() isn't an operator, as it would be grouped with %
I guess… perhaps % and / should be grouped, if we expect types to use /
for pure integer division? (This kinda contradicts my earlier point)
* If the bitwise operators were used for sets (Python does this), you
would use & | ^ but not ~ << >>
Maybe the typeclasses in the Haskell Prelude can provide some
inspiration
(https://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html has
Num, Integral, Fractional, Floating), but this should probably be
fashioned after imagined use-cases: what kinds of types can we imagine
using operator overloading, and what sets of operators would they
implement? From those, reasonable groups could be formed, I guess.
What would be appropriate names for the interface methods? If we just name
them after the operation (like add()), it will become difficult to integrate
these interfaces into existing code, as add() is already a used function
name in many cases, but uses a different signature (non-static with one
argument, whereas the interface needs a static one with two arguments).
I had wanted just ->add(), but you raise a good point that existing code
would probably conflict.
An easy solution could be to prefix all the methods with “operator”?
->operatorAdd(), ->operatorMinus(), ->operatorDivide(),
->operatorBitwiseNot() (to distinguish it from hypothetical future
LogicalNot/BooleanNot) etc…
Thanks,
Andrea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
