On Mon, 3 Jan 2022 at 16:00, Marco Pivetta <ocram...@gmail.com> wrote: > > 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.
Ok for "subtract", I should have thought of that :) Although for me "subtract" sounds like a possibly mutable method, whereas "diff" sounds immutable. This said, I am not really convinced that the current syntax is "good enough". > > 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. For isolated "complex expressions", perhaps. But we should think about algorithms with multiple small math operations, e.g. a foreach with a repeated calculations, some of them in conditional branches, e.g. to calculate prices, taxes, rent etc. In all these operations, we want static analysis to check compatibility of operands. I think these algorithms will become more readable with overloaded operators, while any "embedded formula engine" would make them vastly more complex. Btw others already pointed out that we also want comparison of value objects, not just math. But I came up with the math use cases, so am sticking to it to be fair. Personally I still don't have a clear opinion for or against, but I also don't have voting rights, so... > > 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, Actually we do have query builders, to reduce the amount of literal SQL strings in code, and to make it feel more "native". And where we do have literal SQL, we have to be very careful not to break things, especially when binding or escaping/encoding variables. > and still, SQL is used many magnitudes more than all what was discussed in > this RFC. This may be true currently, for the arithmetics use cases. This said, the reason for a small amount of math libraries in PHP (which I did not actually count) could be exactly because of a lack of overloaded operators. And I think timestamp calculations are already relevant enough in today's code. It would be interesting to see how much overloaded operators are used in Python, and whether the good outweighs the bad. Unfortunately I don't really know where to start looking. > > 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. Interesting. What exactly is going to break BC? > > 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
