Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109388
To: internals@lists.php.net
References: <003701d6013c$9afe9750$d0fbc5f0$@gmx.de>
 <7a83f950a31d94d5ff2307ac8219db3b7b6482b6.camel@schlueters.de>
Date: Sat, 28 Mar 2020 14:43:49 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0)
 Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2
MIME-Version: 1.0
In-Reply-To: <7a83f950a31d94d5ff2307ac8219db3b7b6482b6.camel@schlueters.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [VOTE] Userspace operator overloading
From: ajf@ajf.me (Andrea Faulds)
Message-ID: <php.internals-109388@news.php.net>

Hi Johannes,

Johannes Schlüter wrote:
> I believe the pre-requisit is having some form of function overloading,
> where operator functions for specific argument types can be defined. In
> https://news-web.php.net/php.internals/108425 Andrea created an idea,
> which is probably "ugly" but has less usage restrictions. I think
> spending time on function overloading (I believe, without proving it,
> this can be done with very little cost for non-overlaoded cases - by
> adding a flag "overloaded" along visibility flags and check that along
> with the visibility check, only in case of an overload to the
> "expensive" check, which still is cheaper done in the engine than
> if/else chains in userspace) and then take up operator overloading
> again, rather than this smart but limited approach. (For whoever does
> that: spend time in C++ and its function resolution rules incl. ADL,
> not to copy, but to learn)

Thinking about what I suggested there again now, I think it's a shame 
this RFC includes the following restriction:

 > The argument must not specify any argument typehints (an error is 
thrown otherwise), as typehints and occuring type errors would break 
operator evaluation (see discussion).

With strict evaluation of union types, it would be possible to achieve 
something like what I suggested in a less ugly form:

     class A {
         /* … */
         public function __add(int|float|B $other) {
             /* … */
         }
     }
     class B {
         /* … */
         public function __add(int|C $other) {
             /* … */
         }
     }

 From the union typs in this example, the interpreter could see, without 
having to execute either overloaded method, that A provides an overload 
for B, int and float, and B provides an overload for C and int, and so 
it knows the same method can be called for both `$a + $b` and `$b + $a`, 
likewise for `$b + $c` and `$c + $b`.

Of course, this requires interpreting type declarations in an unusual 
way, and it also needs a solution to non-commutative operators (perhaps 
a second parameter that would contain a boolean specifying whether 
`$this` is on the left), but I think it is less likely to be chaotic 
than the current proposal.

Thanks,
Andrea