Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116660
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> <CAB-BujbjgBBNdLjf+8SxWKJrv3J3CU8Mv51n4AkCwpsOt5WekA@mail.gmail.com>
 <CA+kxMuQc6dJWQLO2JGE-KG6ERSobNdAic0BU8D07r3i1d-t7QA@mail.gmail.com>
In-Reply-To: <CA+kxMuQc6dJWQLO2JGE-KG6ERSobNdAic0BU8D07r3i1d-t7QA@mail.gmail.com>
Date: Thu, 16 Dec 2021 20:24:57 +0100
Message-ID: <CAB-Bujbuo7shBmC=UXJRJJtJsqJdw5CsGE8B58LTFZ-rKpQ47g@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
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)

On Thu, 16 Dec 2021 at 19:20, Dan Ackroyd <Danack@basereality.com> wrote:
>
> On Thu, 16 Dec 2021 at 12:21, Andreas Hennings <andreas@dqxtech.net> wrot=
e:
>
> > Methods and functions have searchable and clickable names. Operators do=
n't.
> > The "searchable" applies to grep searches in code, but also google
>
> That's one of the reasons why I prefer a magic methods based approach.
>
> function __plus(...){}
>
> can be searched for...and for future scope, something like:
>
> function __union(...){}
>
> is more self-documenting (imo) than:
>
> operator  =E2=88=AA(...){}
>

I don't mind using magic methods for this, compared to an operator keyword.
It is also what I found is happening in python.

However, this does not give us searchability in the calling place,
only where it is declared / implemented.


>
> > Lack of real parameter overloading
> > Unlike C++ (or C?), we don't have real method/function overloading
> > based on parameters.
>
> Java is probably a better comparison language than C.
>
> I have a note on the core problem that method overloading would face
> for PHP here: https://phpopendocs.com/rfc_codex/method_overloading
>
> But although they both involved the word 'overloading', operator
> overloading, and method overloading are really separate features.

I see the distinction in overloading based on the object type on the
left, vs overloading based on parameter types.

For a method call $a->f($b), the implementation of ->f() is chosen
based on the type of $a, but not $b.
For an operator call "$a + $b", with the system proposed here, again,
the implementation of "+" will be chosen based on the type of $a, but
not $b.
For native operator calls, the implementation is chosen based on the
types of $a and $b, but in general they are cast to the same type
before applying the operator.
For global function calls f($a, $b), the implementation is always the same.

In a language with parameter-based overloading, the implementation can
be chosen based on the types of $a and $b.

This brings me back to the "symmetry" concern.
In a call "$a->f($b)", it is very clear that the implementation is owned by=
 $a.
However, in an operator expression "$a + $b", it looks as if both
sides are on equal footing, whereas in reality $a "owns" the
implementation.

Add to this that due to the weak typing and implicit casting,
developers could be completely misled by looking at an operator
invocation, if a value (in our case just the left side) has an
unexpected type in some edge cases.
Especially if it is not clear whether the value is a scalar or an object.
With a named method call, at least it is constrained to classes that
implement a method with that name.

>
> > we cannot have the conditional type hints.
>
> btw you can just say 'types'.
>
> Unlike some lesser languages, in PHP parameter types are enforced at
> run-time; they aren't hints. I believe all references to hints (in
> relation to types at least) have been removed from the PHP manual.

Ok, what I mean is return type declarations.
In a class Matrix, operator(Matrix $other): Matrix {} can be declared
to always return Matrix, and operator(float $factor): float {} can be
declared to always return float.
However, with a generic operator(mixed $other): Matrix|float {}, we
cannot natively declare when the return value will be Matrix or float.
(a tool like psalm could still do it)

But even for parameters, if I just say "type" it won't be clear if I
mean the declared type on the parameter, or the actual type of the
argument value.


>
> cheers
> Dan
> Ack