On Mon, Mar 30, 2020 at 1:19 PM Sara Golemon <poll...@php.net> wrote:
> On Mon, Mar 30, 2020 at 10:56 AM Sherif Ramadan <theanomaly...@gmail.com> > wrote: > >> @Sara Golemon <poll...@php.net> >> >> >>> Ditto Danack's question, adding: "Then why not use brick/varexporter?" >>> >>> -Sara >>> >> >> I punt the question back to you and ask why not use PHP? >> >> Simple. Because an implementation in script code is more agile, more > accessible, and more maintainable in the long term. It's better in every > way except default availability. Considering the *1 line* required to make > it available in a project, this is not a compelling reason. Conversely, > avoiding unnecessary breakage of existing code over a matter of aesthetics > IS a compelling reason. > > Now, will you answer my question? > Simple. Because an implement in php-src is more available, does not appear to have a lot of maintenance overhead, is easy to implement and it's better in every way. Considering the 6 lines of code required to make this change available to everyone. Given that code is meant for human consumption and given that aesthetics play a big role in code readability I would say that conversely doing it IS a compelling reason. Apart from the 25 phpt tests that (in my opinion) are testing the wrong thing in the first place, what major projects do you know of that would break as a result of this change? And I'm not talking about more tests that test the output of var_export() because that's a breakage I can live with. If you were using the function as intended you would only be testing that it gives you back valid PHP code and not trying to test its literal output. > -Sara >
