Re: [VOTE] User Defined Operator Overloads

Hello Jordan, do you have any thoughts about these symmetric/left/right modifiers, to get rid of the $operandPos parameter? To me, the parameter could be the kind of thing where in hindsight we ask "why?". Also, can we drop the "public" modifier, if we do a new version of the RFC? Cheers Andreas On Tue, 4 Jan 2022 at 00:27, Andreas Hennings <andreas@dqxtech.net> wrote: > > Hello Jordan, > > I have another note about the RFC. > (I am not sure what's the policy, if we should continue _all_ > discussion here or go back to the RFC thread. Hope it's ok here.) > > OperandPosition::LeftSide > OperandPosition::RightSide > > I wonder if this is the best way to model this. > Especially, it does not account for the case where an operator only > works in one direction, or the allowed operand type is dependent on > the direction. > E.g., (Money / float) is ok, but (float / Money) probably not supported. > Or if it is supported, then the return type will be quite different. > You can throw an exception, but this is not useful for static analysis. > > An alternative syntax with a few more keywords: > > abstract class Money { > symmetric operator * (float|int $other): Money; // Commutative. > left operator / (float|int $other): Money; // Only $a / $b allowed, > $b / $a not possible. > left operator - (Money $other): Money; // $a - $b > right operator - (Money $other): Money; // $b - $a > } > > Btw, in the Matrix example from the RFC, under "When will $operandPos > be useful?", the $operandPos is not really useful, because it will > always pick the default $a - $b version. > The same applies to "-" operator in my Money example, because $other > already implements the operator. > > The $operandPos is only needed if the left operand does _not_ > implement the operator. Which is the case e.g. for complex numbers, or > the Number class from the RFC example. > > I am trying to think of cases where ($a <op> $b) would have a > different type than ($b <op> $a), but I can't think of any. > Or rather, for any case that I could think of, the mirror operator > could simply be provided by $b. > > I am not married to the modifier names, e.g. it could be "symmetric" > or "commutative" or something else. > For left/right perhaps I prefer to talk about the "default direction" > vs the "flipped direction", not sure how this could be turned into > keywords. > If we don't like more keywords, perhaps something like "!operator" for > the flipped version? > > Cheers > Andreas > > On Mon, 3 Jan 2022 at 01:14, Jordan LeDoux <jordan.ledoux@gmail.com> wrote: > > > > Hello internals, > > > > I've opened voting on > > https://wiki.php.net/rfc/user_defined_operator_overloads. > > The voting will > > close on 2022-01-17. > > > > To review past discussions on this RFC and the feature in general, please > > refer to: > > > > - https://externals.io/message/116611 | Current RFC > > discussion > > - https://externals.io/message/115764 | Initial RFC > > discussion > > - https://externals.io/message/115648 | Pre-RFC discussion > > and fact-finding > > > > Jordan