Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116816
MIME-Version: 1.0
References: <CAMrTa2Emxro81j7UMA5QZ+wCOY7g46LSotLRD4oUG7HEfqSD0A@mail.gmail.com>
 <CAB-BujY=RM832fUXUFnq0OFUBVmSQZS4Uog4WCvrD-bVYEuJ9Q@mail.gmail.com>
In-Reply-To: <CAB-BujY=RM832fUXUFnq0OFUBVmSQZS4Uog4WCvrD-bVYEuJ9Q@mail.gmail.com>
Date: Wed, 5 Jan 2022 15:33:32 +0100
Message-ID: <CAB-BujZRRfjGHOyfybDX9MoPwRjNzULUgYQac7hP69QyWSWDzA@mail.gmail.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [VOTE] User Defined Operator Overloads
From: andreas@dqxtech.net (Andreas Hennings)

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