Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112974
To: Rowan Tommins <rowan.collins@gmail.com>, "internals@lists.php.net"
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] var_representation() : readable alternative to
 var_export()
Thread-Index:
 AQHW8R1wWWGP+37l0kiexDpDbUAmVKo1egmAgAAyURKAAR7sgIAAHRckgAA4DACAAAC7mg==
Date: Sun, 24 Jan 2021 19:38:11 +0000
Message-ID:
 <DM6PR07MB661862F3A7031039AAED674EF9BE9@DM6PR07MB6618.namprd07.prod.outlook.com>
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>
 <DM6PR07MB6618ABE1BB0EAC60442154B1F9BE9@DM6PR07MB6618.namprd07.prod.outlook.com>,<8e5d376c-0d7d-bf1b-bcca-3f8c4c737a22@gmail.com>
In-Reply-To: <8e5d376c-0d7d-bf1b-bcca-3f8c4c737a22@gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [A21icHfjZVPWHsWrX6ocuxecTFExsLXbdIcUIw0s1kATsSUONdruXMoOBCtxo5bv]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: d34677dc-6c4b-4c41-d044-08d8c09f95ce
x-ms-traffictypediagnostic: CO1NAM04HT044:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 iFqy9UwxC7NJIbgNdvxiT8lvJRNzaJG5RmA7ktINa3KwkD8cis2mT8o9mF8vsw5nvXEQ0DcsWHDkj41OYsezsb++cBbx4eVOpCt7WnePK5xvyaZKFf4kO4jEs/AbOt6aUbNrfDaOq8iDEHs59uo0qHlVHwinJcJEXl7zM1FE9duNbP5RYAUhIZs28xYY5I55TqJKUFUO1lFIQG2qlzy23VDsnOWJP4ARbpKsI2oq+OvmtUQwl9fUz3TmJEAbsjcSBKK8q+0aMIKvxkrdrvXmfZfDJ8b3LxdpBUrHXSFIJWKPny4KfafSMBXRmvQcosJo+aNTZzyXJQlO3Vq/mMpatINuC8/BIFp4AXa42QIP/Fmsa0bKYNyhNjrzpMSpRyxzB1FCsRTS1vRcASAhjbEuGPowWqTaAeTI3V5bXVT1STM=
x-ms-exchange-antispam-messagedata:
 MGN6pdkSbjDdfogEOy82ue0/cUqeEcBWsQo5B9fT1gPZ4JzUa/pXAPuBShqlkiT7r89NY7t39sP49Q+cYUyX1TNIzx7efJUUeBHYmN55Vu4wyGT7q10MqoAZneqdcM4AFhqmmIrcQh+1Asmna79dno5zQIaH3HlVGHUzlcoRdMwyfcj4edz3fq0IcU8rEIxX/bFnB+u7kud+YfBF6HBfrg==
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: CO1NAM04FT015.eop-NAM04.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: d34677dc-6c4b-4c41-d044-08d8c09f95ce
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2021 19:38:11.7547
 (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: CO1NAM04HT044
Subject: Re: [PHP-DEV] [RFC] var_representation() : readable alternative to
 var_export()
From: tysonandre775@hotmail.com (tyson andre)

Hi Rowan Tommins,=0A=
=0A=
> > **php-src phpt tests are for tests of php itself, which puts strict and=
 atypical limitations on the test framework.**=0A=
> > php-src's phpt test framework may represent needs of php-src and some p=
ecl maintainers, not userland.=0A=
>=0A=
> I'm not sure what point you're trying to make here. You were the one =0A=
> that mentioned php-src tests as a use case, so I looked to see what they =
=0A=
> currently use; the answer is *overwhelmingly* var_dump.=0A=
=0A=
I mentioned php-src test cases a use case for **something that fixes the pr=
oblems with var_export**=0A=
and would make it possible to write shorter phpt tests (input+output) that =
continue to unambiguously represent output.=0A=
=0A=
> > Still, I would prefer using var_representation over var_dump in phpt fo=
r many use cases, especially with VAR_REPRESENTATION_SINGLE_LINE available.=
=0A=
> =0A=
> In the previous thread, you agreed with Sara that var_dump should be =0A=
> "left out of this". Are you now saying that the new function *should* =0A=
> replace some uses of var_dump?=0A=
=0A=
I meant that **changing the output format of print_r and var_dump** should =
be "left out of=0A=
this" RFC discussion.=0A=
=0A=
Yes, I would agree that new or refactored phpt test cases could start using=
 var_representation instead of var_dump=0A=
if this was added to the language and authors preferred it.=0A=
=0A=
> If that is an aim, should we look at what other differences there are =0A=
> between var_dump and var_export, and how we can make this new function =
=0A=
> cover more use cases?=0A=
=0A=
The use case of "generate a (short, readable, escaped) representation of a =
variable that can be evaluated"=0A=
is something I'd consider useful enough on its own, a useful primitive in a=
 modern programming language,=0A=
and not need to cover every use case.=0A=
I don't plan to change the direction of this RFC.=0A=
=0A=
The main features I remember unique to var_dump are as follows (I don't pla=
n to add any of those):=0A=
=0A=
1. var_dump includes object ids, this is useful for telling that objects ar=
e different - if you need to know if objects are equivalent use var_dump or=
 debug_zval_dump or serialize.=0A=
2. String lengths- this is less of a concern with ascii control characters =
escaped in var_representation.=0A=
3. Prefixing scalars with types - only useful for tutorials introducing the=
 type system or debugging=0A=
4. References and recursion - I don't think there's much demand for a predi=
ctable/readable/efficient way to represent that in a readable string. `unse=
rialize()` covers that.=0A=
=0A=
=0A=
> > For a new developer, they may not have those features or plugins instal=
led in their IDE,=0A=
> > or may not be aware of the existence of the shortcut/command to invoke =
those features on a range.=0A=
>=0A=
> I contend that a new developer would very rarely have any need to use =0A=
> this functionality at all.=0A=
=0A=
If a php developer is learning the language through php's official manual, =
official language reference, or through an online tutorial,=0A=
that would have sections showing the different scalar types, examples invol=
ving objects and/or arrays, etc.=0A=
Those use var_export/var_dump=0A=
=0A=
https://www.php.net/manual/en/functions.anonymous.php=0A=
https://www.php.net/manual/en/language.types.string.php=0A=
https://www.php.net/manual/en/language.types.boolean.php=0A=
https://www.php.net/manual/en/language.types.object.php=0A=
=0A=
```=0A=
<?php=0A=
var_dump((bool) "");        // bool(false)=0A=
var_dump((bool) 1);         // bool(true)=0A=
var_dump((bool) -2);        // bool(true)=0A=
```=0A=
=0A=
```=0A=
<?php=0A=
$obj =3D (object) array('1' =3D> 'foo');=0A=
var_dump(isset($obj->{'1'})); // outputs 'bool(true)' as of PHP 7.2.0; 'boo=
l(false)' previously=0A=
var_dump(key($obj)); // outputs 'string(1) "1"' as of PHP 7.2.0; 'int(1)' p=
reviously=0A=
```=0A=
=0A=
> > Additionally, scripts to reindent may not remove the `0 =3D>`, `1 =3D>`=
, etc,=0A=
> > either not containing a php parser or assuming the user deliberately ad=
ded those keys.=0A=
>=0A=
> And maybe they'd be right not to - that's an unavoidable problem with =0A=
> any formatter, it won't be universal.=0A=
>=0A=
> And that is why I'm sceptical of this function: it seems to be mostly a =
=0A=
> different set of arbitrary formatting decisions, which some people will =
=0A=
> prefer and some won't.=0A=
=0A=
And people who don't prefer that formatting are free to continue using var_=
export in their projects.=0A=
=0A=
If people may not prefer that formatting, that would be a reason for introd=
ucing a new function instead of modifying var_export.=0A=
=0A=
Imagining that var_export was never added to the language with those arbitr=
ary formatting decisions=0A=
in PHP 4.2.0 and an RFC was being discussed to add the **first** built-in w=
ay to convert a string to a machine-readable language in PHP 8.1:=0A=
Would we really choose the indentation var_export used?=0A=
Would we advocate putting values on different lines from keys being aware o=
f common coding standards?=0A=
Would we use `array (` with a space instead of `[`?=0A=
=0A=
> The only part that feels like fundamental value is escaping control =0A=
> characters, which could be added to var_dump and/or var_export and only =
=0A=
> affect that minority of a minority of usages which are relying on the =0A=
> exact output in cases where control characters are present.=0A=
=0A=
Minor changes to var_export and var_dump have been proposed in the past =0A=
and met with some hesitance or opposition to any output format changes,=0A=
e.g. the question of whether changing the default output format is=0A=
worth affecting existing libraries/applications/tests.=0A=
https://externals.io/message/106674#106684=0A=
https://externals.io/message/101883=0A=
=0A=
I would be in favor of adding string escaping to var_dump,=0A=
but that is a discussion that should be "left out of this" RFC=0A=
as var_dump has a different purpose.=0A=
=0A=
Regards,=0A=
Tyson=0A=