Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116666
User-Agent: Cyrus-JMAP/3.5.0-alpha0-4524-g5e5d2efdba-fm-20211214.001-g5e5d2efd
Mime-Version: 1.0
Message-ID: <37dc7c09-37dc-44f5-89d5-fd3c1a256492@www.fastmail.com>
In-Reply-To: 
 <CAB-Bujbuo7shBmC=UXJRJJtJsqJdw5CsGE8B58LTFZ-rKpQ47g@mail.gmail.com>
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>
 <CAB-Bujbuo7shBmC=UXJRJJtJsqJdw5CsGE8B58LTFZ-rKpQ47g@mail.gmail.com>
Date: Thu, 16 Dec 2021 17:24:22 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Dec 16, 2021, at 1:24 PM, Andreas Hennings wrote:

> 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.

The RFC covers all of this, and the way it works around it.  Absent method overloading (which I don't expect any time soon, especially given how vehemently Nikita is against it), it's likely the best we could do.


> 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)

I... have no idea what you're talking about here.  The RFC as currently written is not a "generic operator".  It's

operator *(Matrix $other, bool $left): Matrix

The implementer can type both $other and the return however they want.  That could be Matrix in both cases, or it could be Matrix|float, or whatever.  That's... the same as every other return type we have now.

--Larry Garfield