Hey Andreas, On Mon, Jan 3, 2022 at 3:40 PM Andreas Hennings <andr...@dqxtech.net> wrote:
> I imagine that operator overloads can improve DX for these use cases, > but at a cost for the overall language. > > How would you (Marco) see the future of arithmetic libraries for time, > money etc without overloaded operators? > How would these calculations look like e.g. with infix functions? > Do you think this can eliminate the desire for operator overloads? > > E.g. something like this? > > $ts0 = new Timestamp($seconds0); > $ts1 = new Timestamp($seconds1); > /** @var Duration $duration */ > $duration = $ts1 - $ts0; // Operator overload notation. > $duration = Duration::betweenTimestamps($ts0, $ts1); // Static method > notation. > $duration = $ts1->diff($ts0); // Object method notation. > $duration = $ts0 <Duration::betweenTimestamps> $ts1 // Infix notation > based on static method. > $duration = $ts1 <diff> $ts0 // Infix notation based on object method. > 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 ```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 http://twitter.com/Ocramius http://ocramius.github.com/
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
