Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108798
To: internals@lists.php.net
References: <005101d5edae$7b7c3e10$7274ba30$@gmx.de>
Date: Sun, 1 Mar 2020 18:11:52 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0)
 Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2
MIME-Version: 1.0
In-Reply-To: <005101d5edae$7b7c3e10$7274ba30$@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [RFC] Userspace operator overloading
From: ajf@ajf.me (Andrea Faulds)
Message-ID: <php.internals-108798@news.php.net>

Hi Jan,

jan.h.boehmer@gmx.de wrote:
> 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 (~, &, |, ^, <<,
>>> ).

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