Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112944
MIME-Version: 1.0
References: <DM6PR07MB66189CC60F94349200D0D02BF9A40@DM6PR07MB6618.namprd07.prod.outlook.com>
 <CAF+90c9PJ=9NOtLPW_iTaY2=AF97oc6BrXRSqK0+4QNGsYxJbg@mail.gmail.com>
In-Reply-To: <CAF+90c9PJ=9NOtLPW_iTaY2=AF97oc6BrXRSqK0+4QNGsYxJbg@mail.gmail.com>
Date: Wed, 20 Jan 2021 13:59:29 -0600
Message-ID: <CAESVnVrj1FAtP1JiNW9C9xutGS4mZYSKNFj9xQVR=OrRjAFdMg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: tyson andre <tysonandre775@hotmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003fba1805b95a6584"
Subject: Re: [PHP-DEV] Proposal: short_var_export($value, bool $return=false,
 int $flags=0)
From: pollita@php.net (Sara Golemon)

--0000000000003fba1805b95a6584
Content-Type: text/plain; charset="UTF-8"

On Tue, Jan 19, 2021 at 3:59 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

>  * 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

--0000000000003fba1805b95a6584--