Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113052
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Tue, 2 Feb 2021 20:04:50 +0100
References: <DM6PR07MB6618CACB8C7FBF81A2A66A8FF9A20@DM6PR07MB6618.namprd07.prod.outlook.com>
 <VI1PR02MB470385256ADCA1CB1D21419EE2B69@VI1PR02MB4703.eurprd02.prod.outlook.com>
 <DM6PR07MB6618F8D52AEF77719CE96703F9B59@DM6PR07MB6618.namprd07.prod.outlook.com>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <DM6PR07MB6618F8D52AEF77719CE96703F9B59@DM6PR07MB6618.namprd07.prod.outlook.com>
Message-ID:
 <VI1PR02MB47038885EC386DFAE85C8800E2B59@VI1PR02MB4703.eurprd02.prod.outlook.com>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [IPv6:2001:7e8:c83a:5400:30f6:13da:890:c3f8] (2001:7e8:c83a:5400:30f6:13da:890:c3f8) by LO2P265CA0267.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a1::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.17 via Frontend Transport; Tue, 2 Feb 2021 19:04:52 +0000
X-MS-PublicTrafficType: Email
X-IncomingHeaderCount: 46
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-Correlation-Id: 5acd34a2-c42a-43c0-43e4-08d8c7ad6bbe
X-MS-TrafficTypeDiagnostic: VE1EUR02HT202:
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	B9nFUsodqEWv8c3AQBDxzR6gYFLVLa+CmRXlT23bYL5tFhcfV6cSn99FEzJJdDRS/EoYHO4DZSIVV/jJBM2ZgzvfCPv7ny/TXEWtkP0GBItnO+QI3oMIOdcaD7c14a4k6xiD5I4iEVhEOtDAzwGphD8Ta9YkCQREMSRmn5JUT51VjUQhy22fTaMJQ5UFz7z2rfp15F1txBpSLP/OEVij6AtiDmskLQFpl/5Dkk8SFHPveKRDHIGAAQe6VP/hkO5spNcOJepcbdzlz1AY5KntfsWYj3iXTF0Ciyn7t8KFu+ZDuIT/N4sBbaTRSH+6MqLyP73MjFbB9CnmAgPLmh/nmR5jtcY3Uz1t54eGG0SygbPcuc3Ic6bnDaPFg3sEYD0tOl11z6lQUnXaurU10C5eu6Zl5hLjzHEolYMN5wALaOdz3XIp/o3XFHWP79P+T/xd
X-MS-Exchange-AntiSpam-MessageData:
	UXZtFff5WlQdZGhZunrWUbeyW0usL6akHwPgDakVh5drySO7Vj0jopak72RLNiijyoOW531N2JBF1L9n86+i2hFF/VfmQKDiukyWg/mQGGDsU/fSSUR+mml8d2TQF2uzBloXoI2LPYDf2Hc/eWwlL8f3uCk7I+OsAcaCxjrzTURB3wEcDIxNoV5FqQC8+RGUIf/nNcPWfz8jafjL7HDw3A==
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5acd34a2-c42a-43c0-43e4-08d8c7ad6bbe
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2021 19:04:52.8463
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-AuthSource:
	VE1EUR02FT061.eop-EUR02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR02HT202
Subject: Re: [PHP-DEV] [VOTE] Dump results of expressions in `php -a`
From: bobwei9@hotmail.com (Bob Weinand)

Hey Tyson,

> Am 02.02.2021 um 03:35 schrieb tyson andre <tysonandre775@hotmail.com>:
>=20
> Hi Bob Weinand,
>=20
>>> Am 20.01.2021 um 01:55 schrieb tyson andre <tysonandre775@hotmail.com>:
>>>=20
>>> Hi internals,
>>>=20
>>> Voting has started on https://wiki.php.net/rfc/readline_interactive_she=
ll_result_function
>>> on 2021-01-19, and ends on 2021-02-02.
>>>=20
>>> This RFC proposes to dump the results of non-null expressions using var=
_dump/var_export() by default in `php -a` (the interactive shell).
>>> Additionally, this adds a new function `readline_interactive_shell_resu=
lt_function` to the readline PHP module.
>>> This function only affects interactive shells - it can optionally be us=
ed to set or clear a closure when `extension_loaded('readline') =3D=3D=3D t=
rue`,
>>> but that closure would only be called in interactive shells (i.e. php -=
a).
>>> (That closure would be called instead of the native implementation with=
 the snippet of code that was evaluated and the expression's result,
>>> 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)
>>> - Dumping of expression results can be disabled using an ini setting or=
 at runtime=20
>>>=20
>>> Thanks,
>>> - Tyson
>>=20
>> Hey Tyson,
>>=20
>> My main concern in this iteration of the RFC is: what happens with big/d=
eeply nested objects?
>> They tend to spew tons of lines if var_dump()'ed. Do we have reasonable =
depth/output limitations in default dumping mode?
>>=20
>> I'm often enough using php -a to do some quick ad-hoc processing (exampl=
e, read a big json file, and then access a value; instantiating a mediawiki=
 bot framework and calling replace on it; ...).
>>=20
>> It's really cool to have any interactive feedback at all, but please, at=
 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 ex=
pand with your mouse. Obviously with a pure cli application, this needs dif=
ferent - intuitive - navigation.)
>>=20
>> As it currently stands, this makes php -a unusable in any but the simple=
st cases, without just disabling the whole feature.
>>=20
>> 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 wit=
h tons of irrelevant information=E2=80=A6 I don't need that potentially hap=
pening on every single evaluated expression)
>>=20
>> Thus I'm voting no, for now.
>=20
> As-is, the entire object or string would be dumped with var_export/var_du=
mp to stdout.
>=20
> Thoughts on the adding following output truncation mechanism=20
> (for the default C result dumper implementation)
> before printing the results of the returned expression=20
> (the user output continues to be untruncated, and the existence of cli.pa=
ger=20
> would not affect this mechanism in case the binary is not actually a page=
r)?
> For arrays/objects used with var_dump - the equivalent of=20
> `ob_start(); var_dump($result); $result =3D ob_get_clean();`=20
> would have to be used first from C since var_dump still writes to the out=
put buffer (php_printf(), etc.)

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 propert=
y/one array argument =3D single line instead of two lines.
Additionally, when dumping a nested object, it's more valuable to see as mu=
ch as possible from the primary object rather than the deep nesting.


> I'd omitted output truncation from the RFC because I wasn't sure how many=
 people=20
> would consider it excessive to include a limit on var_dump output, and th=
ere was little feedback before the RFC vote started.

Yeah, sorry for the late comment on that :-)

> The simplest implementation would be to truncate to a byte limit and appe=
nd `...` if truncated,=20
> but the main concern that's been brought up is the approximate number of =
lines.
> Obviously, there'd be a value in truncating the output if there were to b=
e megabytes of output,
> though exactly what settings make sense as a default would vary.

As mentioned a section earlier, there should be limits according to the nes=
ting-level =E2=80=A6 e.g. if it's the top-level value, a string may have 20=
 lines printed and array and objects as well. And array entries/properties =
should then be in a single line or take up to max ... 20 / count(properties=
 or array entries) lines (width before truncation can be determine from ter=
minal width), which then can be mostly in one line flattened output.
The general rule here should be, show me my object/array at hand and give m=
e a brief overview of what's nested within - and if I'm interested in detai=
l, let me (manually) output that object.
Also consider, when dumping strings within (nested) arrays/objects to repla=
ce newlines with \n, for nicer display.

> C would not print anything (e.g. `=3D> `) or even call var_dump/var_expor=
t if the limits were set to 0.
>=20
> ```
> <?php
>=20
> const ASSUMED_BYTES_PER_LINE =3D 80;
> const ASSUMED_TAB_WIDTH =3D 4;

On that topic, may make sense to also fetch the actual terminal width and h=
eights respectively (ioctl TIOCGWINSZ).
I.e. if terminal is 20 lines high, printing 20 lines is a lot. if it's 80 l=
ines high, 20 lines is acceptable.

> // unmodified
> var_dump(truncate_string("test short string"));
> // 5000 'A's followed by "...\n"
> var_dump(truncate_string(str_repeat('A', 10000)));
> // 100 lines containing "A" followed by "...\n"
> var_dump(truncate_string(str_repeat("A\n", 10000)));
> ```

I'd wager nobody needs a hundred lines, I'd use inspiration from debuggers =
which typically show 5-20 lines max.
IF you want to print it all, it's just as easy as `echo $var;` though.

So overall: try to make efficient usage of horizontal as well as vertical s=
pace while still remaining usable and readable.

Bob

> Thanks,
> - Tyson