Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112984
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+37l0kiexDpDbUAmVKo1egmAgAAyURKAAR7sgIAAHRckgAA4DACAAAC7moAAL94AgAAYDwA=
Date: Mon, 25 Jan 2021 14:40:38 +0000
Message-ID:
 <DM6PR07MB6618AB7B7814D6E0E88DFAB4F9BE9@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>
 <DM6PR07MB661862F3A7031039AAED674EF9BE9@DM6PR07MB6618.namprd07.prod.outlook.com>,<cd5b7420-6706-4d20-f0ee-9c42c718e1a3@gmail.com>
In-Reply-To: <cd5b7420-6706-4d20-f0ee-9c42c718e1a3@gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [S5/jX+lnd/P0vbz8E5DtnRffufcuJ3Y1In6xGlbNRH+mOouyvgRqF0txM0KpK/iD]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 1eb5b467-a265-4c71-7117-08d8c13f2e8d
x-ms-traffictypediagnostic: DM6NAM12HT192:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 0ad4XQaFV1VZqMQLI/9W1QpDsM7yS8/M+jEqakP4XGeCQc4TBPlQr/dy7Enztnxo1qvdvyd8/38axwzAQutbuygHB77c1IpGdWRsB1yaNwveTwUM/NnM8P0zJFBNKru9xtdNCFwRWXaRDB4tgU7TDIKx4Fjtt2mseFxheaLV9O4+mEvd8lz4HXMY4XIQATHyo7Z0/39cq3WDiMkyw93j79p9PJ9zRqzMa92dDbBjXNP8ajlhcC2x+EALkBSKqUdE9kn+ookIwn86U/70Hm6SJJ/GvBy43KqOVYpA8W0xJ+s=
x-ms-exchange-antispam-messagedata:
 nWhQ0skH96/MYY8ol/58df997X350uqMpqlWFJjL5Ra7+J8NE4bMoYiBZB6CMj4E9bq6WTGOoz0H8fzGyt/FU1srZiQ+jxQ8Qzvf1imfLCIOXVy7GtOm7UV59/nySzeq/I0jJg0iZIZ7tlOmh4FUKBDDQRwrDh/gJXQszacyfxMx+LZL/WOli341psm/wKFbiSKTmakT650OtLxSTulw1Q==
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: DM6NAM12FT033.eop-nam12.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 1eb5b467-a265-4c71-7117-08d8c13f2e8d
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2021 14:40:38.0437
 (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: DM6NAM12HT192
Subject: Re: [PHP-DEV] [RFC] var_representation() : readable alternative to
 var_export()
From: tysonandre775@hotmail.com (tyson andre)

Hi Rowan,=0A=
=0A=
> > If a php developer is learning the language through php's official manu=
al, official language reference, or through an online tutorial,=0A=
> > that would have sections showing the different scalar types, examples i=
nvolving 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=
> Every single one of those uses var_dump, and I see no reason why they =0A=
> should use anything different.=0A=
=0A=
Sorry, I misread your comment as being about the family of debug output fun=
ctions as a whole.=0A=
=0A=
I'd agree var_dump is the most appropriate for these.=0A=
if the manual depended on printf or `var_export(); echo "\n";` then a devel=
oper new to programming=0A=
might have to read the printf documentation or echo documentation or concat=
enation documentation first to better understand the examples.=0A=
=0A=
If php were to add a `puts()` or `println()` function that would automatica=
lly append a newline=0A=
then that might also work better in tutorials longer-term, e.g. `puts(var_r=
epresentation($value))`.=0A=
The fact that php was originally for "personal home pages"=0A=
may explain why this isn't currently part of the standard library,=0A=
since newlines are mostly treated like whitespace in most html elements exc=
ept `<textarea>`, etc.=0A=
=0A=
> > The use case of "generate a (short, readable, escaped) representation o=
f 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=
> =0A=
> I guess I just don't agree. I think the use case of "generate a =0A=
> representation that can be evaluated" is adequately covered by =0A=
> var_export, the "short" is mostly irrelevant, and the "readable" mostly =
=0A=
> opinion-based. The "escaped" sounds useful, but more as an enhancement =
=0A=
> to the current function (with a flag, if compatibility is really an =0A=
> issue) than a ground-up re-design.=0A=
=0A=
I had considered that option, but had expected more pushback because of htt=
ps://github.com/php/php-src/pull/6619#issuecomment-765809096=0A=
and the discussion on the prior RFC email threads on improving var_export.=
=0A=
=0A=
1. Passing too many arguments to var_export would cause a ArgumentCountErro=
r=0A=
   or warning before php 8.1 if flags were added to var_export=0A=
2. If that approach was used, I'm concerned PHP may indefinitely keep the d=
efault behavior of `array (`, `NULL`, etc. in var_export.=0A=
    (changing the default behaviour of var_export significantly may discour=
age some users from upgrading php due to libraries/applications that depend=
 on it)=0A=
3. It is practical to polyfill var_representation for php 8.0 and older and=
 allow applications to use it immediately after 8.1 is released, but less s=
o for var_export.=0A=
=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=
> Sorry, I'm really confused here. On the one hand, most of your examples =
=0A=
> are of things that currently use var_dump; on the other hand, you insist =
=0A=
> that improving var_dump is a completely unrelated topic. Surely if =0A=
> var_dump was improved, that would influence the choice of function in =0A=
> those use cases?=0A=
=0A=
You have proposed no mechanism other than string escaping by which var_dump=
 could or should be improved.=0A=
=0A=
var_dump accepts a variadic list of objects, so $flags or $options can't be=
 added to it even if you wanted opt-in enhancements like single line repres=
entation.=0A=
As I said earlier, var_dump always prints to stdout, which may get mixed wi=
th error handler output or stdout if ob_start() is used..=0A=
=0A=
I don't expect var_dump to be changed in a way that would make the output p=
ossible to `eval()`;=0A=
eval()able output representation is what I'm working on.=0A=
=0A=
Regards,=0A=
Tyson=