Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113058
To: Bob Weinand <bobwei9@hotmail.com>, PHP internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [VOTE] Dump results of expressions in `php -a`
Thread-Index: AQHW7sXh/djsjqFFPU2LB2XOuWtB1qpDg3qAgAC0oVGAARboAIABQ4ah
Date: Wed, 3 Feb 2021 14:39:51 +0000
Message-ID:
 <DM6PR07MB6618DB8DAE483A8A66D6F88FF9B49@DM6PR07MB6618.namprd07.prod.outlook.com>
References:
 <DM6PR07MB6618CACB8C7FBF81A2A66A8FF9A20@DM6PR07MB6618.namprd07.prod.outlook.com>
 <VI1PR02MB470385256ADCA1CB1D21419EE2B69@VI1PR02MB4703.eurprd02.prod.outlook.com>
 <DM6PR07MB6618F8D52AEF77719CE96703F9B59@DM6PR07MB6618.namprd07.prod.outlook.com>,<VI1PR02MB47038885EC386DFAE85C8800E2B59@VI1PR02MB4703.eurprd02.prod.outlook.com>
In-Reply-To:
 <VI1PR02MB47038885EC386DFAE85C8800E2B59@VI1PR02MB4703.eurprd02.prod.outlook.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [QclATnSZ0d8Pjh5qol8zpuDj9yeq3Of9m7j6LeoJGhI4wa0LFAXUdG0XhZl4T6CM]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 8aaab991-662a-4faf-e91e-08d8c85190ad
x-ms-exchange-slblob-mailprops:
 K3wx5smWY1PDlWuW6pOTfeWUGh4UG+cV5AuGCgVPHc7XnbaPcx+bIn1jhFp4uQh7TjihdfURz5rSvJZpWsTeBciChWaEwk7YcfW0EHaW+e3yaEJNvpBzhCSgz5U2HIxUQ7TEB34+YmZOoWBIPbd/U7788Xl/w4N1EzdsoM1hHzvH1lbcSlERhWt/InhuWKevr6+d4pca2qzHoHJqI72TMKkwIf7mAU1Osfvcxbst7HA62mTRUd6dLhruGX/wb+o1h2hRJ2pyWKhExfEaAhbB94PXtOtU4Ex6srIjLHOBhARN8U9Thj7R6nkQzRis1f5wGQ98ILup2JOTgzmIEBim+LT63HomiVYnUN/wIcyVlR+GndGjKXih+qw/r2jbU6ZxLVhJFDkc25tLoms/OgYBBVfYQy/thF8M03raK6uy+9MR4acXrT7Sy+5re6GdoLcDa9SmNLVuqiPhqrvPLgef1IO8mQiT18iyfQVO5jmJKcEDSRbKI7xbdwXGk2vAPftaIRdRpEgrsw2sSJBclPLop41eCwc1Y9Jj1QoRWnovV2S19a8Wb+aHPrR6NFT3AzJ2pMGrBOQqV9hODqhM/86N1H61I4xW2nCCGbBZ4kGzLiERLMyU4PseV/oiiuEgwOcp7t7Bb9/VQ4aUkXme7MutAECDJ6WspOZTHCbRmG50rv5KbgvzVPhLFuX5GoU7Xp8xGYGSy2YJgTj7nO3r3GT/AuSIvuJkkoQapC5OQD+qTBp9sB7uplTC+2tlmCBk8y+OUSJoZcz1EEHuVphbUgUReesMGwCLJU4usyOq93F49mj36rDqq7mu4ssf/m7e2TulChTmqFUJy+q3Nv7JA5stxG8JMNBKEtf0JDNXop3lEnsFQu9OLYPK/fqoMjz5sSIFUgyjII5T6BV6xkfb+7L1iCfV+aD9PIGC1Yyn0RC2acg=
x-ms-traffictypediagnostic: CY1NAM02HT193:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 pm8ABJRro5kx4M0Aefqy7XZbb9t+BVJ4+kfxw78Y20r8ZjJ9D0oT/KnCSqu9Y1PJgC3anfAO+eqw4qUesFxboaYVTjVeclknpOymAOUWnh8SI83rVi8F+e/uLGDcQkwadbB2YOFmiKrwC5f7m5qQxtQkhOjiCxXNbflCGunr3IOnJu4p1YMBLQyV5cYGwlg8OC6QnkfuPo2vELUl70rTHDJybn0W0zEH8Zme+RbB/IXqyVMdRk9jdKkgmtGu3eBKPUQpnEv8vMKMMjR+dAAxc35j4TQnh692X3/4ftSQ38lzVUNtGXUUvspcw6ZS1uOvgbe3zUfxkppyRReTboanrcQ99DQozCNA4i3uanC7Js9nSaykk7+RSOlj1kt6TWm5wf94NtZBeajcq1M2Tg9IvCDojNRuoAAF3tECGaCFMtab7kZ6m35DWvjxybcARXdA
x-ms-exchange-antispam-messagedata:
 cKzEXpxgQyzlxfq/Yxf4hE741noGhwLgceCoiaYPU+yIc66d9nH8UYkuTESwdkMTcZs++1Y1/i5sNe+YrCcSdAgwgK8Vt896QDCjy0DdPo4e7lTFBbzzoxDWv3W3O3i0xActHBL3Cr5lga9FSk20A1KklX0Q5JsKShdlxuWxqXNekKwA7QDvnn/vDQadSoiu+FRRQn0w59BqhPbV0+BaJQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: CY1NAM02FT010.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 8aaab991-662a-4faf-e91e-08d8c85190ad
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2021 14:39:51.6998
 (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: CY1NAM02HT193
Subject: Re: [PHP-DEV] [VOTE] Dump results of expressions in `php -a`
From: tysonandre775@hotmail.com (tyson andre)

Hi Bob Weinand,=0A=
=0A=
>>>> Voting has started on https://wiki.php.net/rfc/readline_interactive_sh=
ell_result_function=0A=
>>>> on 2021-01-19, and ends on 2021-02-02.=0A=
>>>>=0A=
>>>> This RFC proposes to dump the results of non-null expressions using va=
r_dump/var_export() by default in `php -a` (the interactive shell).=0A=
>>>> Additionally, this adds a new function `readline_interactive_shell_res=
ult_function` to the readline PHP module.=0A=
>>>> This function only affects interactive shells - it can optionally be u=
sed to set or clear a closure when `extension_loaded('readline') =3D=3D=3D =
true`,=0A=
>>>> but that closure would only be called in interactive shells (i.e. php =
-a).=0A=
>>>> (That closure would be called instead of the native implementation wit=
h the snippet of code that was evaluated and the expression's result,=0A=
>>>> if a php statement contained a single expression such as `2+2;` or `$x=
 =3D [1,2];` (that could be used as the expression of a return statement)=
=0A=
>>>> - Dumping of expression results can be disabled using an ini setting o=
r at runtime=0A=
>>>>=0A=
>>>> Thanks,=0A=
>>>> - Tyson=0A=
>>>=0A=
>>> Hey Tyson,=0A=
>>>=0A=
>>> My main concern in this iteration of the RFC is: what happens with big/=
deeply nested objects?=0A=
>>> They tend to spew tons of lines if var_dump()'ed. Do we have reasonable=
 depth/output limitations in default dumping mode?=0A=
>>>=0A=
>>> I'm often enough using php -a to do some quick ad-hoc processing (examp=
le, read a big json file, and then access a value; instantiating a mediawik=
i bot framework and calling replace on it; ...).=0A=
>>>=0A=
>>> It's really cool to have any interactive feedback at all, but please, a=
t least by default, limit the output. (An example is the JS REPL in browser=
 console - it shows you a minimal preview of the object, and then you can e=
xpand with your mouse. Obviously with a pure cli application, this needs di=
fferent - intuitive - navigation.)=0A=
>>>=0A=
>>> As it currently stands, this makes php -a unusable in any but the simpl=
est cases, without just disabling the whole feature.=0A=
>>>=0A=
>>> I like the whole feature, but the missing output limitation (I have yet=
 enough nightmares from var_dump()'ing the wrong object filling my shell wi=
th tons of irrelevant information=85 I don't need that potentially happenin=
g on every single evaluated expression)=0A=
>>>=0A=
>>> Thus I'm voting no, for now.=0A=
>>=0A=
>> As-is, the entire object or string would be dumped with var_export/var_d=
ump to stdout.=0A=
>>=0A=
>> Thoughts on the adding following output truncation mechanism=0A=
>> (for the default C result dumper implementation)=0A=
>> before printing the results of the returned expression=0A=
>> (the user output continues to be untruncated, and the existence of cli.p=
ager=0A=
>> would not affect this mechanism in case the binary is not actually a pag=
er)?=0A=
>> For arrays/objects used with var_dump - the equivalent of=0A=
>> `ob_start(); var_dump($result); $result =3D ob_get_clean();`=0A=
>> would have to be used first from C since var_dump still writes to the ou=
tput buffer (php_printf(), etc.)=0A=
>=0A=
>var_dump() tends to be quite intensive in newline usage. I don't think var=
_dump() (as is) is the best mechanism to print. At least I'd use one proper=
ty/one array argument =3D single line instead of two lines.=0A=
>Additionally, when dumping a nested object, it's more valuable to see as m=
uch as possible from the primary object rather than the deep nesting.=0A=
>=0A=
>=0A=
>> I'd omitted output truncation from the RFC because I wasn't sure how man=
y people=0A=
>> would consider it excessive to include a limit on var_dump output, and t=
here was little feedback before the RFC vote started.=0A=
>=0A=
>Yeah, sorry for the late comment on that :-)=0A=
>=0A=
>> The simplest implementation would be to truncate to a byte limit and app=
end `...` if truncated,=0A=
>> but the main concern that's been brought up is the approximate number of=
 lines.=0A=
>> Obviously, there'd be a value in truncating the output if there were to =
be megabytes of output,=0A=
>> though exactly what settings make sense as a default would vary.=0A=
>=0A=
>As mentioned a section earlier, there should be limits according to the ne=
sting-level =85 e.g. if it's the top-level value, a string may have 20 line=
s printed and array and objects as well. And array entries/properties shoul=
d then be in a single line or take up to max ... 20 / count(properties or a=
rray entries) lines (width before truncation can be determine from terminal=
 width), which then can be mostly in one line flattened output.=0A=
>The general rule here should be, show me my object/array at hand and give =
me a brief overview of what's nested within - and if I'm interested in deta=
il, let me (manually) output that object.=0A=
>Also consider, when dumping strings within (nested) arrays/objects to repl=
ace newlines with \n, for nicer display.=0A=
>=0A=
>> C would not print anything (e.g. `=3D> `) or even call var_dump/var_expo=
rt if the limits were set to 0.=0A=
>>=0A=
>> ```=0A=
>> <?php=0A=
>>=0A=
>> const ASSUMED_BYTES_PER_LINE =3D 80;=0A=
>> const ASSUMED_TAB_WIDTH =3D 4;=0A=
>=0A=
>On that topic, may make sense to also fetch the actual terminal width and =
heights respectively (ioctl TIOCGWINSZ).=0A=
>I.e. if terminal is 20 lines high, printing 20 lines is a lot. if it's 80 =
lines high, 20 lines is acceptable.=0A=
>=0A=
>> // unmodified=0A=
>> var_dump(truncate_string("test short string"));=0A=
>> // 5000 'A's followed by "...\n"=0A=
>> var_dump(truncate_string(str_repeat('A', 10000)));=0A=
>> // 100 lines containing "A" followed by "...\n"=0A=
>> var_dump(truncate_string(str_repeat("A\n", 10000)));=0A=
>> ```=0A=
>=0A=
>I'd wager nobody needs a hundred lines, I'd use inspiration from debuggers=
 which typically show 5-20 lines max.=0A=
>IF you want to print it all, it's just as easy as `echo $var;` though.=0A=
>=0A=
>So overall: try to make efficient usage of horizontal as well as vertical =
space while still remaining usable and readable.=0A=
=0A=
I'm not sure if I want to do anything that complicated or if there'd be a c=
onsensus on how to indent each level.=0A=
Having the same rules at any indent level would be my preference.=0A=
=0A=
Another idea I'd had would be to add a new function=0A=
`var_dump_as_string(mixed $value, int $use_placeholders_after_lines =3D -1,=
 int $use_placeholders_after_lines =3D -1)` to=0A=
=0A=
1. Escape control characters in the same way as the proposed var_representa=
tion=0A=
2. Replace remaining fields with `...` if the line limits or byte limits wo=
uld be exceeded by adding a key-value pair=0A=
   in arrays/objects that have more fields. (go back and truncate the strin=
g if necessary)=0A=
3. Possibly revisit other representation choices, e.g. put values on the sa=
me lines as keys=0A=
=0A=
```=0A=
php > echo var_dump_as_string(range(0,99), use_placeholder_after_lines: 5);=
=0A=
array(100) {=0A=
  [0]=3D>int(0)=0A=
  [1]=3D>int(1)=0A=
  ...=0A=
}=0A=
php > var_dump("a\n\"b");=0A=
string(4) "a=0A=
"b"=0A=
php > echo var_dump_as_string("a\n\"b");=0A=
string(4) "a\n\"b"=0A=
```=0A=
=0A=
This would have the following benefits:=0A=
=0A=
1. In addition to being usable in an interactive shell/REPL,=0A=
   it would be possible to use this in other libraries/applications where d=
umping too much debug output is a concern,=0A=
   or to invoke it manually (e.g. through a userland wrapper function `v($v=
alue)`) when debugging.=0A=
   (where recursion detection and object ids are useful to have when debugg=
ing)=0A=
2. Performance and memory usage would be less of a concern when dumping ext=
remely large objects.=0A=
3. This would avoid the chance of mixing php code output from `__debugInfo`=
/notices with the outputted string,=0A=
   which is possible with ob_start()/ob_get_clean()=0A=
4. Avoid mixing in control characters such as newlines with debug output wh=
en a var_dump-like representation is needed.=0A=
=0A=
-Tyson=0A=