Le 03/01/2022 à 16:00, Marco Pivetta a écrit :
I'd probably use `$ts1->subtract($ts0)`, which doesn't seem to be that
unreadable, and there is no need to abbreviate it to "diff" either.
Whether it needs to be static methods or instance methods depends on
the wished API design.
What this RFC aims at is a mathematical language, inside another
general purpose language: for complex expressions, I'd probably run it
in a subsystem dedicated to this instead.
See for example:
* https://en.wikipedia.org/wiki/Expression_(mathematics) (I'm
literally just picking a complex example - don't even know how to read
that properly)
* and its textual representation in
https://en.wikipedia.org/w/index.php?title=Expression_(mathematics)&action=edit§ion=1
<https://en.wikipedia.org/w/index.php?title=Expression_(mathematics)&action=edit§ion=1>
```php
$expression = <<<'MATH'
f(a)+\sum_{k=1}^n\left.\frac{1}{k!}\frac{d^k}{dt^k}\right|_{t=0}f(u(t))
+ \int_0^1 \frac{(1-t)^n }{n!} \frac{d^{n+1}}{dt^{n+1}} f(u(t))\, dt.
MATH;
$result = $userlandExpressionEngine->evaluate(
$expression,
[
// ... bind parameters here ....
]
);
```
Heck, I can probably ask the `$userlandExpressionEngine` to render
that monstrosity for me (see attachment).
Note that we do this stuff constantly for SQL, yet we haven't designed
a system for embedding SQL into the language, and still, SQL is used
many magnitudes more than all what was discussed in this RFC.
Yes, strings are problematic to some degree, but it's still better
than increasing language complexity for a very edge case.
Alternatively, a better way to embed other languages can be used,
which would be much more useful for things like Twig, Blade, PHPTal,
SQL, etc: In haskell, this is done via Template Haskell, which many
like, and many loathe, but is still useful for type-safe operations
with a different language than the "main" one:
https://wiki.haskell.org/A_practical_Template_Haskell_Tutorial#Shakespearean_Templates
In addition to all the above, I just noticed that the entire
reflection API in the RFC requires major BC breaks in the reflection
API... sigh.
Marco Pivetta
Hello,
I personally tend to agree with everything that Marco said. Especially
regarding the fact that it's adding huge complexity to the language
itself for mostly edge cases.
I'd argue there's many much more valuable features that could be added
to PHP before operator overload, such as generics, rationalized
collection API and scalar objects with methods for example (which all
could be magnificent tools for improving the operator overload RFC).
I'm not against explicit method call, it's both readable and navigable,
whereas operator overload tend to magically hide what the code really does.
Best regards,
--
Pierre
