Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113086
To: Nikita Popov <nikita.ppv@gmail.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] Re: [RFC] var_representation() : readable alternative
 to var_export()
Thread-Index: AQHW8R1wWWGP+37l0kiexDpDbUAmVKpIIyDYgABZb4CAAFEIuw==
Date: Fri, 5 Feb 2021 01:30:35 +0000
Message-ID:
 <DM6PR07MB661804F82D1E374DB29D5B13F9B29@DM6PR07MB6618.namprd07.prod.outlook.com>
References:
 <DM6PR07MB66184CC05829642BD4E16E3AF9BF9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <DM6PR07MB66189F7D092F98F05BE7AEA2F9B39@DM6PR07MB6618.namprd07.prod.outlook.com>,<CAF+90c-Vyu-z0v6ZjisSen62Pd=nFxVWi1Y8KhY5jqms0nPsUg@mail.gmail.com>
In-Reply-To:
 <CAF+90c-Vyu-z0v6ZjisSen62Pd=nFxVWi1Y8KhY5jqms0nPsUg@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [DCL48jAzA9JYsKEHIEMIwIxUqdmr+e96K2yUYaH+wfZcWv5SN67aYdY9opmgwR/Y]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: c997a40d-af4f-4925-0a2c-08d8c975a2ca
x-ms-traffictypediagnostic: DM6NAM11HT088:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 RLcoVsimaiB8O5Y1DjpsVyrsxd/szG8zNfwQOsYjlLJZzRZD/Akxe3Ru2SWQWCTkihl8P2QGEsNrhhzTwZo6/yO2Zvdk8Uvf3S8kzLoNXQ8GUvfHaTJoc6JF2yvjPv1+yXctYcVcMj1VF3DohUVvcH7Y6tM26pNQh54JzVrPR3JHf97RAWIYKFHwJPX2utIfOWQ1FiOhmiqwlDTm3hmVPKBF9spSJ34HsCTRKsX6gu/STbVB1a16ZRytzG3+H4S96naN/twOn7dcl//E7BvIOP0hJMLoXG2yHmK/XggeAv1FSEIVURfqC5dYOAhUqYwm4eyX+qpqgC+UhPCTIIyG9acJvNW92+hzNKjeTuzHN78OK9RY8fIrDCBF+/V6wCeRcC+LV6ABfoxjoXBteXQbOyPKgGwlq45WVSZdHOa8im8=
x-ms-exchange-antispam-messagedata:
 jWndCYhtQ9a40HQ7GmrbFbBcZE1kDYVweXYLlOTkmAYuXro9wqEjr8ocxwi+DP3JRc8FQz5ojgCprZLmEddlNxSfxT0HzgVMJfWXM16nGeKFtQHV/P8Yhhj2/Jca1uNyCbxc6+bfaBNz5V1J667H6Rf2gLl/QtHI4QQvZWAJ1GroXA5QRFuzxVOM9gz0HxzzJGogYLcSNdg2VLqagjoolw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT012.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: c997a40d-af4f-4925-0a2c-08d8c975a2ca
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2021 01:30:35.1502
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM11HT088
Subject: Re: [PHP-DEV] Re: [RFC] var_representation() : readable alternative
 to var_export()
From: tysonandre775@hotmail.com (tyson andre)

Hi internals,=0A=
=0A=
> > > I've created=A0https://wiki.php.net/rfc/readable_var_representation=
=A0based on=0A=
> > > my original proposal in https://externals.io/message/112924=0A=
> > > =0A=
> > > This RFC proposes adding a new function `var_representation(mixed $va=
lue, int $flags=3D0): string`=0A=
> > > with the following differences from var_export:=0A=
> > > =0A=
> > > 1. var_representation() unconditionally returns a string=0A=
> > > 2. Use `null` instead of `NULL` - lowercase is recommended by more co=
ding=0A=
> > > =A0=A0 guidelines (https://www.php-fig.org/psr/psr-2/).=0A=
> > > 3. Change the way indentation is done for arrays/objects.=0A=
> > > =A0=A0 See ext/standard/tests/general_functions/short_var_export1.php=
t=0A=
> > > =A0=A0 (e.g. always add 2 spaces, never 3 in objects, and put the arr=
ay start on the=0A=
> > > =A0=A0 same line as the key)=0A=
> > > 4. Render lists as `"['item1']"` rather than `"array(\n=A0 0 =3D> 'it=
em1',\n)"`=0A=
> > > =0A=
> > > =A0=A0 Always render empty lists on a single line, render multiline b=
y default when there are 1 or more elements=0A=
> > > 5. Prepend `\` to class names so that generated code snippets can be =
used in=0A=
> > > =A0=A0 namespaces without any issues.=0A=
> > > 6. Support `VAR_REPRESENTATION_SINGLE_LINE` in `$flags`.=0A=
> > > =A0=A0 This will use a single-line representation for arrays/objects,=
 though=0A=
> > > =A0=A0 strings with embedded newlines will still cause newlines in th=
e output.=0A=
> > > 7. If a string contains control characters("\x00"-"\x1f" and "\x7f"(b=
ackspace)),=0A=
> > > =A0=A0 then represent the entire string as a double quoted string=0A=
> > > =A0=A0 escaping `\r`, `\n`, `\t`, `\$`, `\\`, and `\"`, in addition t=
o escaping remaining control characters=0A=
> > > =A0=A0 with hexadecimal encoding (\x00, \x7f, etc)=0A=
> > > =0A=
> > > This is different from my original proposal in two ways:=0A=
> > > 1. The function signature and name changed from my previous proposal.=
=0A=
> > > =A0=A0=A0 It now always returns a string.=0A=
> > > 2. Backspace control characters (\x7f) are now also escaped.=0A=
> > =0A=
> > A reminder that voting on the var_representation RFC starts in a day.=
=0A=
> > This RFC proposes adding a new function `var_representation(mixed $valu=
e, int $flags=3D0): string` with multiple improvements on `var_export()`.=
=0A=
> > =0A=
> > Any other feedback?=0A=
> =0A=
> Given the recent discussion in the interactive shell thread,=0A=
> I think you should consider whether the new function could also be expand=
ed to serve that use case.=0A=
> I think that if we're going to add one more dumping function to the 4 we =
already have,=0A=
> it better cover all the use-cases we have.=0A=
> The "limited size dump" doesn't really fit in with "dump is executable PH=
P code",=0A=
> but if I understand correctly, executable PHP code is not the whole goal =
of the proposal.=0A=
=0A=
I suppose that technically could be done by adding a VAR_REPRESENTATION_DEB=
UG_DUMP flag to a $flags bitmask to generate var_dump output,=0A=
and allow that to be combined with VAR_REPRESENTATION_SINGLE_LINE and other=
 style flags.=0A=
I should at least mention it as an option - that possibly combines unrelate=
d functionality (Debug vs evaluable code) in flags,=0A=
but at least it cuts down on the number of different functions.=0A=
I don't plan to include that in this RFC.=0A=
=0A=
-----=0A=
=0A=
I have considered it but think that readable executable PHP code and debug =
representations are largely incompatible - =0A=
having a function to generate executable PHP code that generates a truncate=
d representation of a value doesn't seem as useful.=0A=
If you're generating code to eval() - you're usually generating all of it.=
=0A=
=0A=
For example, for this=0A=
=0A=
```=0A=
php > $x =3D (object)[]; $v =3D [$x, $x]; echo var_representation($v);=0A=
[=0A=
  (object) [],=0A=
  (object) [],=0A=
]=0A=
```=0A=
=0A=
In an application where the identity or use of refereinces in the object di=
dn't matter (e.g. read but not modified), that might be the best representa=
tion.=0A=
=0A=
A hypothetical function could emit `'(static function () { $t1 =3D (object)=
[]; return [$t1, $t1]; })();'`=0A=
if it detected object duplication or references (and so on),=0A=
and likely be faster at generating output than a userland implementation su=
ch as https://github.com/brick/varexporter=0A=
(and avoid limitations of ReflectionReference only being able to check indi=
vidual pairs at a time),=0A=
but I'm concerned that there's not much interest in that, and the response =
would be "this should go in a PECL instead"=0A=
due to the complexity of an implementation, edge cases that unserialize sol=
ves but not the hypothetical function, and due to the ongoing requirement t=
o maintain it.=0A=
- e.g. some internal classes forbid `newInstanceWithoutConstructor()`=0A=
- If an application needed all of the functionality of serialize, it's alre=
ady possible to generate a call to unserialize instead.=0A=
=0A=
I feel like trying to do everything at once would increase the scope to the=
 point=0A=
where the RFC and implementation would be hard to implement and review.=0A=
with only a few people responding so far with mixed feedback I think it's t=
oo early to do that.=0A=
There's other orthogonal improvements =0A=
(e.g. Internal objects don't implement `__set_state` (alternately, have a w=
ay to specify a constructor classes support instead of dumping `__set_state=
`)=0A=
(`ArrayObject::__set_state`, `SplObjectStorage::__set_state`, `GMP::__set_s=
tate`, etc. currently do not exist))=0A=
=0A=
Thanks,=0A=
Tyson=0A=