Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101883
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain dqxtech.net from 209.85.215.42 cause and error)
MIME-Version: 1.0
Date: Sun, 18 Feb 2018 01:27:47 +0100
Message-ID: <CAH0Uv3FHt8m6WBoH5x4M8tkWAZfW=spzvLcOCGOjpVeFGxV7mg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: var_export() array format
From: andreas@dqxtech.net (Andreas Hennings)

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