var_export() array format

6 years ago by Andreas Hennings — view source

unread

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

6 years ago by David Rodrigues — view source

unread

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

6 years ago by Andreas Hennings — view source

unread

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..

6 years ago by Derick Rethans — view source

unread

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

6 years ago by Paul Jones — view source

unread

What we can do is add a third parameter with flags.

Big +1. When writing tests and setting the $expected value, one of the constantly recurring drudgeries is reformatting the correct var_export($actual) output from arrays to match the surrounding code style. This would reduce that tedium by an order of magnitude.

--
Paul M. Jones
pmjones@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

6 years ago by Derick Rethans — view source

unread

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.

To iterate the purpose of var_export():

Output a variable structure in such a way that PHP can read it back in
by parsing it. Anything else, is just being nice.

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

As opinions are going to differ on what is the "right way", expect that
part of the discussion to turn into bike-shedding.

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 think this is all a big overkill, especially when you take into the
account the purpose of var_export.

cheers,
Derick