On Sun, 18 Feb 2018, Andreas Hennings wrote: > On 18 February 2018 at 02:04, David Rodrigues <david.pro...@gmail.com> wrote: > > I just think that is not responsability of PHP to care about output format > > at core level (although we have the json pretty output support...). > > Why not? > E.g. JSON_PRETTY_PRINT is something I use a lot, often in situations > where I don't or cannot use a 3rd party package. > E.g. > - if I abuse 3v4l.org as a php console > - in a one-off single-file cli script > - in a debugging session, or any temporary code. > - if my involvement with the project is not deep enough to justify > adding a dependency > > > > > Maybe you can found some solution with packages. > > See the last section of my initial message: > >> > >> Why not a userland implementation? > >> E.g. https://packagist.org/packages/riimu/kit-phpencoder > >> > >> var_export() is often used in experimental code or when just playing > >> around, situations where developers usually prefer to avoid adding a > >> 3rd party dependency. > >> Also there is no way to add a 3rd party dependency on e.g. 3v4l.org. > >> And a custom one-off implementation is not what developers should > >> spend their time on (although I did it a few times already). > > If we already have a native function that generates PHP code, then we > should expect it to produce usable output..
It is already useable. From the documentation: var_export — Outputs or returns a parsable string representation of a variable If you want to be able to control the formatting, that's just best done in a userland package. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php, or become my Patron: https://www.patreon.com/derickr twitter: @derickr and @xdebug
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php