Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116822
MIME-Version: 1.0
References: <CAMrTa2Emxro81j7UMA5QZ+wCOY7g46LSotLRD4oUG7HEfqSD0A@mail.gmail.com>
 <CAB-BujY=RM832fUXUFnq0OFUBVmSQZS4Uog4WCvrD-bVYEuJ9Q@mail.gmail.com>
 <CAB-BujZRRfjGHOyfybDX9MoPwRjNzULUgYQac7hP69QyWSWDzA@mail.gmail.com>
 <CAMrTa2G=YyMGkA8zpqgdRhwunx3bYx+J56OsOM0iCXZOz5zoiQ@mail.gmail.com> <CAB-BujaPLZvPZ1MKvf3GB9QGKM0Ps+JAMUBpSd0a5P3XeGBKJw@mail.gmail.com>
In-Reply-To: <CAB-BujaPLZvPZ1MKvf3GB9QGKM0Ps+JAMUBpSd0a5P3XeGBKJw@mail.gmail.com>
Date: Wed, 5 Jan 2022 15:42:46 -0500
Message-ID: <CAPKYkKznXctGrjDUKqOzz7KJj-=5OuKL+LLto0JOcioimo_=iQ@mail.gmail.com>
To: Andreas Hennings <andreas@dqxtech.net>
Cc: Jordan LeDoux <jordan.ledoux@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000083908605d4dbcc4d"
Subject: Re: [PHP-DEV] [VOTE] User Defined Operator Overloads
From: chasepeeler@gmail.com (Chase Peeler)

--00000000000083908605d4dbcc4d
Content-Type: text/plain; charset="UTF-8"

On Wed, Jan 5, 2022 at 3:24 PM Andreas Hennings <andreas@dqxtech.net> wrote:

> On Wed, 5 Jan 2022 at 20:11, Jordan LeDoux <jordan.ledoux@gmail.com>
> wrote:
> >
> >
> >
> > On Wed, Jan 5, 2022 at 6:33 AM Andreas Hennings <andreas@dqxtech.net>
> wrote:
> >>
> >> 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
> >
> >
> > It's a totally different design concept (symmetric/left/right) and I've
> been going over the design implications before I responded. For instance,
> wouldn't this be a special case of method overloading? You're overloading
> according to a modifier, not the typing, but there is that to contend with.
> If someone defined `symmetric operator +` and `left operator +` which would
> be used? (My feeling is left as its more specific.)
>
> You would not be allowed to provide both on the same class.
>
> A class can provide either no operator, or the left operator, or the
> right operator, or both.
> A "symmetric" operator is a shortcut to providing both left and right,
> but using the same implementation.
> A class with a "symmetric" operator cannot also have a "left" or
> "right" version of the same operator - this would be the same as two
> methods with the same name.
> However, if the parent class has a "symmetric" operator, you _can_
> override the "left" and/or "right" version in the subclass. In that
> case, if the subclass provides "left", then the parent "symmetric"
> implementation would only be used for the "right" direction.
>
> I am writing "right" and "left" here, but perhaps "normal" and
> "inverted" would be less ambiguous.
> Also, perhaps instead of "symmetric" we could write "left right".
>
> Perhaps this code will clarify:
>
> class C {
>   symmetric operator * (int $other) {..}
>   # left operator * (int $other) {..} // -> Error, already defined.
>   left operator - (int $other) {..}
>   right operator - (int $other) {..}
>   left operator / (float $other) {..}
>   left operator % (D $other) {..}
> }
>
> class D {
>   right operator % (C $other) {..}
> }
>
> (new C()) * 5; // -> symmetric operator *
> 5 * (new C());  // -> symmetric operator *
> (new C()) - 5;  // -> left operator -
> 5 - (new C());  // -> right operator -
> (new C()) / 5;  // -> left operator /
> 5 / (new C());  // -> Error, no operator provided.
>
> (new C()) % (new D());  // -> left operator % provided by C.
> (new D()) % (new C());  // -> Error, not supported.
>
> This means, the "right operator" will only ever be called if the left
> side does not provide a "left operator".
>
> Basically this is not so different from your RFC.
> Just instead of having to do a "if ($operandPos ===
> OperandPosition::LeftSide) {..}" inside an implementation, we are
> providing two separate implementations.
>
>
> > How would they be stored within the zend_class_entry? Since they would
> technically have the same name, something would need to happen for them to
> not be in the function table.
>
> The right and left version would need to be distinguished somehow
> internally.
> I would say "left" is the default, and "right" has a modifier to its name.
> Perhaps for symmetric operators, we could store two distinct entries
> internally, if that makes things easier.
>
>
If nothing else symmetric could be handled by having the compiler replace
it with left/right version that executes the same code


> >
> > The public modifier is not required (as stated in the RFC), you can just
> add it if you want. Are you asking for `public operator` to produce a
> compile error?
>
> That would be the idea.
> Perhaps others will disagree.
> Allowing the "public" introduces a meaningless choice that people can
> argue about in their code style, and have pointless git commits where
> they add or remove the modifier based on preference.
> Of course the same could be said about "public" in interface methods.
>
>
I personally don't like it when I don't have a consistent look to my code.
One of the things that bother me is code like:
function foo(){}
protected function bar(){}
function baz(){}

I want everything to have a visibility indicator for visual consistency.
That's why I always use public in my interface methods as well. So, even
though it won't cause confusion if omitted for an operator, since it can
only be public, I still think it should be allowed.


> -- Andreas
>
> >
> > Jordan
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepeeler@gmail.com

--00000000000083908605d4dbcc4d--