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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
