var_export() array format

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