Hello internals,
>register_operator(*, function (Foo $lhs, Bar $rhs): Foo { ...});
>register_operator(*, function (Bar $lhs, Foo $rhs): Foo { ...});
>register_operator(*, function (int $lhs, Foo $rhs): int { ...});
>
>But this just brings a new set of problems, including visibility issues
>(i.e. can't use private fields in the implementation), and the fact that
>this requires executing a function at runtime rather than being defined at
>compile time.
Since this is going deeply into magic land anyways, we could go another step
further
and make this a builtin/"macro" that does happen at compile-time, but also can
impose additional restrictions on what is
allowed - namely, that the registered function must not be inlined but a static
method on one of the arguments.
For example: (syntax completely imaginary here but slightly inspired by rust):
register_operator!(+, lhs: Bar, rhs: Foo, ret: Bar, Bar::addFooBar);
register_operator!(+, lhs: Bar, rhs: Bar, ret: Bar, Bar::addBar);
register_operator!(+, lhs: int, rhs: Bar, ret: int, Bar::addBarInt);
register_operator!(+, lhs: Foo, rhs: int, ret: Foo, Foo::addFooInt,
commutative: true);
with
class Bar {
...
public static addFooBar (Bar $bar, Foo $foo): Bar { }
// etc.
}
Advantages:
- Explicitly named methods that can be called/tested separately
- Slightly improved searchability - grepping "register_operator" will show all
operator
combinations inside a code base
- Cannot implement operators for arbitrary classes that one does not own - the
method
must be from one of the operands
- Multiple distinct methods per operand/class without full method overloading
- No restrictions around having scalar types only as rhs
If I am not mistaken, the engine should also be able to typecheck the methods
to ensure that the types are correct, and additionally also be able to disallow
overlaps (eg. defining Foo+Bar commutitatively as well as Bar+Foo),
which should throw an error as soon as the second definition is encountered.
Disadvantage: This sounds like a lot of work to implement, and I am not sure
if the checks are even possible the way I'm imagining them (with classes being
loaded on demand, etc.).
Also, this syntax would definitely need work, I just wanted to point out that
on the
drawing board, many of these design problems are solvable.
Whether they are worth the effort, and whether this is a good idea at all, is
left
for others to decide.
Regards,
Mel
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
