Andreas Hennings
[PHP-DEV] var_export() array format
February 18, 2018 01:30AM
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
David Rodrigues
Re: [PHP-DEV] var_export() array format
February 18, 2018 02:10AM
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" <[email protected]>
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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Andreas Hennings
Re: [PHP-DEV] var_export() array format
February 18, 2018 02:20AM
On 18 February 2018 at 02:04, David Rodrigues <[email protected]> wrote:
> 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..

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Paul Jones
Re: [PHP-DEV] var_export() array format
February 18, 2018 03:50AM
> On Feb 17, 2018, at 18:27, Andreas Hennings <[email protected]> wrote:
>
> 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




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Derick Rethans
Re: [PHP-DEV] var_export() array format
February 20, 2018 10:50AM
On Sun, 18 Feb 2018, Andreas Hennings wrote:

> 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

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Derick Rethans
Re: [PHP-DEV] var_export() array format
February 20, 2018 10:50AM
On Sun, 18 Feb 2018, Andreas Hennings wrote:

> On 18 February 2018 at 02:04, David Rodrigues <[email protected]> wrote:
> > 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login