Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116776
Content-Type: multipart/alternative;
 boundary="------------MvAbjfjZ6OLnIPqtZvFJo7rK"
Message-ID: <3225c921-9b26-d2e0-f76f-45fff6f5a12a@processus.org>
Date: Mon, 3 Jan 2022 16:52:04 +0100
MIME-Version: 1.0
Content-Language: en-US
To: internals@lists.php.net
References: <CAMrTa2Emxro81j7UMA5QZ+wCOY7g46LSotLRD4oUG7HEfqSD0A@mail.gmail.com>
 <CADyq6sKP6fztfF54e_VTHJRMcB8b0_TahMTTY0hw8LAgciY61w@mail.gmail.com>
 <CAB-BujZB31Ccw6nhN9PG1-VDqt8YkijsYUBYPxJ-Ss1Ng4KJ+w@mail.gmail.com>
 <CADyq6sLh+e74qeMrOuX1_PdN40Jw7m=3wMGMmdF-rwXkJLS1mg@mail.gmail.com>
In-Reply-To: <CADyq6sLh+e74qeMrOuX1_PdN40Jw7m=3wMGMmdF-rwXkJLS1mg@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] User Defined Operator Overloads
From: pierre-php@processus.org (Pierre)

--------------MvAbjfjZ6OLnIPqtZvFJo7rK
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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&section=1 
> <https://en.wikipedia.org/w/index.php?title=Expression_(mathematics)&action=edit&section=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

--------------MvAbjfjZ6OLnIPqtZvFJo7rK--