Hi Sara Golemon,
> * 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.
There's 3 drawbacks I don't like about that proposal:
1. If a function taking a stream were to throw or encounter a fatal error while
converting an object to a stream, then you'd write an incomplete object to the
stream or file, which would have to be deleted
E.g. internally, fprintf() and printf() calls sprintf before writing
anything to the stream for related reasons.
2. This may be much slower and end users may not expect that - a lot of small
stream writes with dynamic C function calls would be something I'd expect to
take much longer than converting to a string then writing to the stream.
(e.g. I assume a lot of small `echo $str;` is much faster than
`\fwrite(\STDOUT, $str);` in the internal C implementation)
(if we call serialize() first, then there's less of a reason to expose
serializeFile() and serializeStream)
3. Adding even more ways to dump to a stream/file. Should that include stream
wrappers such as `http://`?
For something like XML/YAML/CSV, that makes sense because those are formats
many other applications/languages can consume,
which isn't the case for var_export.
> ** 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()`.
If I were to go with that in the RFC, the signature would be
`var_export_something($value, bool $return=false, int $flags=0)`
> 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.
My main concern is that
1. I would want to deal with recursive data structures somehow, probably by
throwing or printing *recursion*.
Supporting reentrancy such as `$this->encode($mixedValue, $depth + 1)` is
possible, or possibly just limiting to strings.
Overriding strings may be useful for binary data that's invalid utf-8, but
that can also be done by passing
`['flags' => $flags, 'string_encoder' => $callback, 'indent' => '🐍']`
if the global function's functionality were to be extended to allow other
functionality in a future rfc.
2. I don't know how often the functionality of extending `VarExporter` would be
used in practice.
Userland alternatives such as https://github.com/brick/varexporter/ already
exist for extremely customizable output such as putting scalars all on the same
line
3. Using classes adds verbosity, making it more likely for code to keep using
`var_export($var, true)` over `(new \VarExporter())->serialize($var)`
-Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
