Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112977
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
In-Reply-To: <a810bb03-f32f-bde5-9c48-bd0dbb3b7149@gmail.com>
Date: Sun, 24 Jan 2021 16:24:43 -0800
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <8A960D21-CA74-436F-97FF-B8D76E6D8703@woofle.net>
References: <DM6PR07MB66184CC05829642BD4E16E3AF9BF9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <5ae166a8-378e-b3bc-056a-8ccf4f3a1ddd@gmail.com>
 <DM6PR07MB661825BCB913F64BB24A1510F9BF9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <a810bb03-f32f-bde5-9c48-bd0dbb3b7149@gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] [RFC] var_representation() : readable alternative to
 var_export()
From: dusk@woofle.net (Dusk)

On Jan 24, 2021, at 05:42, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
> As far as I know I have never had any reason to generate code and then =
eval() it, and can't think of a situation where I ever would. If I =
wanted a machine-readable output from a variable, I would use =
serialize() or json_encode().
>=20
> That's not to say that there aren't cases where those requirements do =
happen, but I think it is a very niche use case to dedicate two =
different built-in functions to.

There's an interesting edge case where this does become useful. If an =
evaluable representation of a data structure is written to a file =
(wrapped with `<?php return $x;`) and subsequently loaded using =
`require()`, the file can be stored in opcache. This is dramatically =
faster than unserialize() or json_decode(), especially for large =
structures.

What'd be particularly useful for this use case would be a function =
which behaved similarly to `var_export()`, but which didn't pretty-print =
its output, so as to yield a smaller file.=