Re: [RFC] var_representation() : readable alternative to var_export()

From: Date: Sun, 24 Jan 2021 21:41:06 +0000
Subject: Re: [RFC] var_representation() : readable alternative to var_export()
References: 1 2 3 4 5 6 7  Groups: php.internals 
Request: Send a blank email to internals+get-112975@lists.php.net to get a copy of this message 
On 24/01/2021 19:38, tyson andre wrote:

If a php developer is learning the language through php's official manual, official language reference, or through an online tutorial,
that would have sections showing the different scalar types, examples involving objects and/or arrays, etc.
Those use var_export/var_dump

https://www.php.net/manual/en/functions.anonymous.php
https://www.php.net/manual/en/language.types.string.php
https://www.php.net/manual/en/language.types.boolean.php
https://www.php.net/manual/en/language.types.object.php



Every single one of those uses var_dump, and I see no reason why they should use anything different.



The use case of "generate a (short, readable, escaped) representation of a variable that can be evaluated"
is something I'd consider useful enough on its own, a useful primitive in a modern programming language



I guess I just don't agree. I think the use case of "generate a representation that can be evaluated" is adequately covered by var_export, the "short" is mostly irrelevant, and the "readable" mostly opinion-based. The "escaped" sounds useful, but more as an enhancement to the current function (with a flag, if compatibility is really an issue) than a ground-up re-design.



Imagining that var_export was never added to the language with those arbitrary formatting decisions
in PHP 4.2.0 and an RFC was being discussed to add the **first** built-in way to convert a string to a machine-readable language in PHP 8.1:
Would we really choose the indentation var_export used?
Would we advocate putting values on different lines from keys being aware of common coding standards?
Would we use array ( with a space instead of [?



No, I agree with all of those things, if PHP had no such function right now.

But it does, and the changes don't seem significant enough to me to bother duplicating it.



I would be in favor of adding string escaping to var_dump,
but that is a discussion that should be "left out of this" RFC
as var_dump has a different purpose.



Sorry, I'm really confused here. On the one hand, most of your examples are of things that currently use var_dump; on the other hand, you insist that improving var_dump is a completely unrelated topic. Surely if var_dump was improved, that would influence the choice of function in those use cases?

Regards,

-- 
Rowan Tommins
[IMSoP]

Thread (17 messages)

« previous php.internals (#112975) next »