Proposal: short_var_export($value, bool $return=false, int $flags=0)

Hi Tyson,

The formatting of var_export is certainly a recurring complaint, and
previous discussions were not particularly open to changing current
var_export behavior, so adding a new function seems to be the way to
address the issue (the alternative would be to add a flag to var_export).

I like the idea of the "one line" flag. Actually, this is the main part I'm
interested in :) With the one line flag, this produces the ideal formatting
for PHPT tests that want to print something like "$v1 + $v2 = $v3". None of
our current dumping functions are suitable for this purpose (json_encode
comes closest, but has edge cases like lack of NAN support.)

Some note:

• You should drop the $return parameter and make it always return. As this
  is primarily an export and not a dumping function, printing to stdout
  doesn't make sense to me.
• For strings, have you considered printing them as double-quoted and
  escaping more characters? This would avoid newlines in oneline mode. And
  would allow you to escape more control characters. I also find the current
  '' . "\0" . '' format for encoding null bytes quite awkward.
• I don't like the short_var_export() name. Is "short" really the primary
  characteristic of this function? Both var_export_pretty and
  var_export_canonical seem better to me, though I can't say they're great
  either. I will refrain from proposing real_var_export() ... oops :P

Regards,
Nikita

Sorry for the plug, but you may be interested in getting inspiration from
brick/varexporter:

https://github.com/brick/varexporter

In particular:

• uses short array syntax always

• doesn't output array keys for lists

• can output lists of scalars on one line, under a flag:
  INLINE_NUMERIC_SCALAR_ARRAY

• Benjamin

Hi Nikita,

The formatting of var_export is certainly a recurring complaint, and previous discussions were not particularly open to changing current var_export behavior, so adding a new function seems to be the way to address the issue (the alternative would be to add a flag to var_export).

I like the idea of the "one line" flag. Actually, this is the main part I'm interested in :) With the one line flag, this produces the ideal formatting for PHPT tests that want to print something like "$v1 + $v2 = $v3". None of our current dumping functions are suitable for this purpose (json_encode comes closest, but has edge cases like lack of NAN support.)

Some note:
 * You should drop the $return parameter and make it always return. As this is primarily an export and not a dumping function, printing to stdout doesn't make sense to me.

It seems inconsistent and prone to bugs when refactoring (e.g. converting to string and not using the result)
to have two functions named var_export where one prints by default and the other doesn't, but otherwise .
Changing to a different name entirely would solve that, such as var_repr(), var_representation(), serialize_[value_]as_php_snippet(), etc.

 * For strings, have you considered printing them as double-quoted and escaping more characters? This would avoid newlines in oneline mode. And would allow you to escape more control characters. I also find the current '' . "\0" . '' format for encoding null bytes quite awkward.

I'd considered that but wasn't sure if anyone else would want that - I also found it annoying for \0 and \n, as well as other control characters (0x00-0x1f, e.g. \r\t)

 * I don't like the short_var_export() name. Is "short" really the primary characteristic of this function? Both var_export_pretty and var_export_canonical seem better to me, though I can't say they're great either. I will refrain from proposing real_var_export() ... oops :P

Potentially not shorter with the extra backslash and the potential for switching to "$var\0\ntest\" for string encoding.

var_representation($var, int $flags=0) seems clearer

Thanks,
Tyson

• You should drop the $return parameter and make it always return. As this
  is primarily an export and not a dumping function, printing to stdout
  doesn't make sense to me.

I'd argue the opposite. If dumping a particularly large tree of elements,
serializing that to a single string before then being able to write it to
file or wherever seems like packing on a lot of unnecessary effort. What I
would do is expand the purpose of the $output parameter to take a stream.
STDOUT by default, a file stream for writing to include files (one of the
more common uses), or even a tmpfile() if you do actually want it in a var.

** Or.... See my comment about objects further down.

• I don't like the short_var_export() name. Is "short" really the primary
  characteristic of this function? Both var_export_pretty and
  var_export_canonical seem better to me, though I can't say they're great
  either. I will refrain from proposing real_var_export() ... oops :P

I would also make var_export the dominant part of the name, so
var_export_SOMETHING().

Alternatively how about making a VarExporter class.

$exporter = new VarExporter; // Defaults to basic set of encoding options
TBD
$exporter->setIndent(' '); // 2 spaces, 1 tab, whatever blows your dress up
$exporter->setUserShortArray(false); // e.g. use array(...)
etc...

$serialized = $exporter->serialize($var); // Exports to a var
$exporter->serializeToFile($var, '/tmp/include.inc'); // Exports to a file
$exporter->serializeToStream($var, $stream); // Exports to an already open
stream

And if you want the defaults, then just:

$serialized = (var VarExporter)->serialize($var);

Potentially, one could also allow overriding helper methods to perform
transformations along the way:

// VarExporter which encodes all strings as base64 blobs.
class Base64StringVarExporter extends VarExporter {
public function encodeString(string $var): string {
// parent behavior is `return '"' . addslashes($var) . '"';
return "base64_decode('" . base64_encode($var) . "')";
}
}

Not the most performant thing, but extremely powerful.

-Sara

Le 20 janv. 2021 à 19:50, Rowan Tommins rowan.collins@gmail.com a écrit :

Should we be aiming for a single function that can take over from some or all of the others, and deprecate them, rather than just adding to the confusion?

Or short_var_export() could just reuse the existing __debugInfo() magic method (which is already used by both var_dump() and print_r, but not by var_export()). The programmer would just need to make sure that __set_state() can consume the array produced by __debugInfo().

—Claude