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.led...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
