Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116654
MIME-Version: 1.0
References: <CAMrTa2FB-EVGq29oLCU8fYkMYi+KsQiEAFv1xxMFO7vnm8e6=Q@mail.gmail.com>
 <44b3fb4b-4693-1639-c8c0-5e17296c196e@gmail.com> <CAMrTa2E9STK3G52mnQ9UsrUqi_bH4SMUzcE76PEGcxcLzGPVZA@mail.gmail.com>
 <4b58c011-ed87-ba87-201d-0cf8e4116c6f@processus.org>
In-Reply-To: <4b58c011-ed87-ba87-201d-0cf8e4116c6f@processus.org>
Date: Thu, 16 Dec 2021 13:21:17 +0100
Message-ID: <CAB-BujbjgBBNdLjf+8SxWKJrv3J3CU8Mv51n4AkCwpsOt5WekA@mail.gmail.com>
To: Pierre <pierre-php@processus.org>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
From: andreas@dqxtech.net (Andreas Hennings)

Hello internals,
some concerns I have about operator overloading.
(I have seen and played with operator overloading long time ago in
C++, this is my background for these points.)

----

1. Searchable names.
Methods and functions have searchable and clickable names. Operators don't.
The "searchable" applies to grep searches in code, but also google
searches for documentation and support.
This adds to the concerns already raised by others, that we will see
arbitrary operators "just because we can".

----

2. Symmetry
Operators like "+" or "=3D=3D" are often expected to be symmetric / commuta=
tive.
(for "*" I would not universally expect this, e.g. matrix
multiplication is not symmetric)
https://en.wikipedia.org/wiki/Commutative_property
https://en.wikipedia.org/wiki/Symmetric_function
Having one side of the operator "own" the implementation feels wrong,
and could lead to problems with inheritance down the line.

From C++ I remember that at the time, there was a philosophy of
defining and implementing these kinds of operations outside of the
objects that hold the data.

----

3. Lack of real parameter overloading
Unlike C++ (or C?), we don't have real method/function overloading
based on parameters.
I also don't see it being added in this operator RFC (and I would
disagree with adding it here, if we don't add it for functions/methods
first).
We have to solve this with inheritance override, and with if ($arg
instanceof ...) in the implementation.
What this does not give us is conditional return types:

This is what I would do in a language with parameter-based overloading:

class Matrix {
  operator * (Matrix $other): Matrix {..}
  operator * (float $factor): Matrix {..}
  operator * (Vector $vector): Vector {..}
}

class Vector {
  operator * (Vector $vector): float {..}
  operator * (float $factor): Vector {..}
}

(Or if we also have templates/generics, we could put dimension
constraints on the types, so that we cannot multiply matrices where
dimensions mismatch.)

Without real parameter overloading, we have to use instanceof instead,
and we cannot have the conditional type hints.


-- Andreas



On Thu, 16 Dec 2021 at 09:24, Pierre <pierre-php@processus.org> wrote:
>
> Le 16/12/2021 =C3=A0 05:01, Jordan LeDoux a =C3=A9crit :
> > This is not a use case I highlighted because it's one that would be
> > difficult to support with this RFC. But as you say, it could be a good
> > future expansion. In particular, putting a query builder object into co=
re
> > with some more advanced overloads built in may be the best way to
> > accomplish this, particularly if it is built with the idea in mind that=
 the
> > entities themselves may also have overloads.
> >
> > I can certainly add it to the future scope of this RFC however.
> >
> > --
> >
> > RE: The operator keyword and operator implementations being non-callabl=
e.
> >
> > This was a limitation that I purposely placed on the operator keyword, =
as I
> > didn't like the idea of allowing syntax of the style `$obj->{'+'}();` o=
r
> > `$obj->$op();` and I wanted developers to clearly understand that they
> > shouldn't treat these as normal methods in the vast majority of
> > circumstances. However, it seems this is one of the largest sticking po=
ints
> > for those who would otherwise support the RFC. To that end, I'm conside=
ring
> > removing that restriction on the `operator` keyword. If I were to do th=
at,
> > you'd no longer need to wrap the operator in a closure to call it, thou=
gh
> > the parser would still have problems with `$obj->+(...);`
> >
> > I suppose my question then would be, is this an acceptable compromise o=
n
> > the operator keyword? It removes one of the more annoying hurdles that
> > Danack mentioned and that others have pointed out, but retains much of =
the
> > benefits of the keyword that I expressed in my last email.
> >
> > Jordan
>
> Hello,
>
> I'm not an internals hacker nor someone who can vote, but here is my
> opinion about operator overloading: I don't like it. Nevertheless, if it
> has to be done, I'd like it to be less challenging for PHP newcomers or
> everyday developers.
>
> An operator is not much more than a function shortcut, gmp examples
> prove that point quite well. I don't see why it is necessary to create a
> new syntax. It seems in the discussion that the magic method ship has
> sailed, but I'd much prefer it.
>
> I don't see why a user wouldn't be able to call an operator
> method/function outside of the operator context. It has a signature:
> left operand and right operand are its parameters, and it has a return
> type. The engine internally will just call this function as userland
> code could do.
>
> I think that adding a new syntax for it, and allowing weird function
> names which are the operator symbols will probably create some mind fuck
> in people's mind when reading the code. I like things being simple, and
> I'd love operator overloads to be simple functions, no more no less, not
> "a new thing". The more PHP syntax grows the more complex it is to learn
> and read.
>
> Regarding the naming debate about operator names being different
> depending upon the context, I agree, but I don't care, if operators have
> a name in the engine, I'd prefer methods to carry the same name even if
> it yields a different name in the domain semantics of the object: if you
> are the low level operator function developer, you know what you are
> doing furthermore you can still comment code. If you're the end user,
> you will read the domain API documentation, not the code itself in many
> cases.
>
> If the names are a problem, why not registering those using an attribute
> ? If I remember well it was mentioned somewhere in the mail thread, it
> would provide a way to explicitly register any method, with any name, as
> being an operator implementation, sus userland could keep both syntax
> and use the one they wish (i.e. $newNumber =3D $number->add($otherNumber)=
;
> or $newNumber =3D $number + $otherNumber. It's not insane to keep this
> possibility open, on the contrary, it'd leverage the fact that operator
> overloading in some context is just a shiny eye candy way of writing
> some domain function shortcut.
>
> That's my opinion and I don't if it worth a penny, but in my mind, an
> operator is a function, and there's no reason that it'd be a different
> thing.
>
> Regards,
>
> --
>
> Pierre
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>