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 ()".
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
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 ()".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#51351Another 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 tovar_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
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..
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_PRINTis 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 dependencyMaybe 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
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
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 ()".
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
--
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