Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101884
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH0Uv3FHt8m6WBoH5x4M8tkWAZfW=spzvLcOCGOjpVeFGxV7mg@mail.gmail.com>
References: <CAH0Uv3FHt8m6WBoH5x4M8tkWAZfW=spzvLcOCGOjpVeFGxV7mg@mail.gmail.com>
Date: Sat, 17 Feb 2018 23:04:12 -0200
Message-ID: <CAEsg9X01oaAZ4bDpdJkSWM=J4sdRi+VbnxNdvVnLn-5KbumHBA@mail.gmail.com>
To: Andreas Hennings <andreas@dqxtech.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a114a9bf8ea553a05657227ff"
Subject: Re: [PHP-DEV] var_export() array format
From: david.proweb@gmail.com (David Rodrigues)

--001a114a9bf8ea553a05657227ff
Content-Type: text/plain; charset="UTF-8"

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...).

Maybe you can found some solution with packages.

Em 17 de fev de 2018 10:28 PM, "Andreas Hennings" <andreas@dqxtech.net>
escreveu:

> I sometimes use var_export() to export a structured array and then
> copy+paste it into my code.
> And sometimes I use it as part of an automatic code generator.
>
> Unfortunately, the output is usually not in the format that I want, or
> that is common for most projects / code styles.
>
> - Indentation is 2 spaces instead of 4, as in most projects.
> - It uses traditional "array()" format, instead of "[]".
> - It puts a space after "array", so "array (" instead of "array(".
> - It puts "array (" on a new line after "=>", instead of "'key' =>
> array(" on one line.
> - Empty arrays occupy two lines instead of one, so "array (\n)"
> instead of "array ()".
>
> E.g. https://3v4l.org/nl4uJ
>
> The IDE can fix some of these problems with a single operation. Others
> require cumbersome manual treatment.
> E.g. my IDE (PhpStorm) cannot automatically remove the line break
> between "=>" and "array (".
>
> Code generators can be designed to fix all of the problems, but imo
> they should not have to deal with this stuff.
>
> ------
>
> ## Proposed change
>
> I really think the default behavior of var_export() must remain
> unchanged for BC.
> Re-running the same script in different PHP versions should produce
> the same output each time.
>
> What we can do is add a third parameter with flags.
> Then we can introduce named flag combinations for known code styles.
>
> Flag constants could be
> - VAR_EXPORT_INDENT_TAB
> - VAR_EXPORT_INDENT_2
> - VAR_EXPORT_INDENT_3
> - VAR_EXPORT_INDENT_4
> - VAR_EXPORT_ARRAY_SHORT_SYNTAX for "[]" instead of "array (..)".
> - VAR_EXPORT_ARRAY_NO_INITIAL_BREAK for " => array (" instead of "
> =>\n  array(".
> - VAR_EXPORT_ARRAY_NO_INITIAL_SPACE for "array(" instead of "array (".
> - VAR_EXPORT_ARRAY_ONELINE_IF_EMPTY
>
> From other discussions:
> - VAR_EXPORT_STDCLASS_AS_CAST for "(object)array (.." instead of
> "stdClass::__set_state(array(..))".
> - VAR_EXPORT_FQCN for "\stdClass" and "\Acme\Animal" instead of
> "stdClass" and "Acme\Animal".
>
> The naming is open for debate, of course.
>
> I prefixed all array-related constants with *_ARRAY_* so that they
> group up more nicely.
>
> I considered for a moment to prefix the constants with "PHP_" or
> something else instead of "VAR_EXPORT_", so they could be used
> elsewhere in the future.
>
> ------
>
> For a short time I considered to mix all this into the second
> parameter which currently only accepts boolean.
> Once you use any non-zero flags, it would always return.
> For my taste, the print-by-default is a bad idea anyway.
>
> But I now think a third parameter would be more transparent and clean.
>
> The indentation could be solved with a 4th parameter instead of
> *_INDENT_* constants.
> See https://externals.io/message/51345#51351
>
> Another alternative would be to introduce yet another function which
> always returns, has a more useful default format, and where the second
> parameter accepts flags like mentioned above.
> But somehow it feels wrong to me to introduce such a new function
> which mostly does the same as an already existing one.
> But most of them are quite specific to var_export(), and would not
> make sense elsewhere.
>
> ------
>
> 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).
>
> -----
>
> -- Andreas
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a114a9bf8ea553a05657227ff--