On Mon, 3 Jan 2022 at 16:00, Marco Pivetta <ocramius@gmail.com> wrote:
>
> Hey Andreas,
>
> On Mon, Jan 3, 2022 at 3:40 PM Andreas Hennings <andreas@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?
