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
