Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112971
To: "internals@lists.php.net" <internals@lists.php.net>
References: <DM6PR07MB66184CC05829642BD4E16E3AF9BF9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <5ae166a8-378e-b3bc-056a-8ccf4f3a1ddd@gmail.com>
 <DM6PR07MB661825BCB913F64BB24A1510F9BF9@DM6PR07MB6618.namprd07.prod.outlook.com>
Message-ID: <a810bb03-f32f-bde5-9c48-bd0dbb3b7149@gmail.com>
Date: Sun, 24 Jan 2021 13:42:27 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <DM6PR07MB661825BCB913F64BB24A1510F9BF9@DM6PR07MB6618.namprd07.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] var_representation() : readable alternative to
 var_export()
From: rowan.collins@gmail.com (Rowan Tommins)

On 23/01/2021 21:07, tyson andre wrote:
> I've added those to https://wiki.php.net/rfc/readable_var_representation#when_would_a_user_use_var_representation
> , including when I think the VAR_REPRESENTATION_SINGLE_LINE flag would be useful to users.


Thanks, it's good to at least know your opinion on this, even if I don't 
fully agree with it. :)


> var_representation  may be useful to a user when any of the following apply:
>
> - You are generating a snippet of code to eval() in a situation where the snippet will occasionally or frequently be read by a human  (If the output never needs to be read by a human, `return unserialize(' . var_export(serialize($data), true) . ');` can be used)


As far as I know I have never had any reason to generate code and then 
eval() it, and can't think of a situation where I ever would. If I 
wanted a machine-readable output from a variable, I would use 
serialize() or json_encode().

That's not to say that there aren't cases where those requirements do 
happen, but I think it is a very niche use case to dedicate two 
different built-in functions to.


> - You are writing unit tests for applications supporting PHP 8.1+ (or a var_representation polyfill) that test the exact string representation of the output (e.g. phpt tests of php-src and PECL extensions)


Since test output doesn't need to be executable, I would have thought 
var_dump would be more appropriate than var_export here.

Checking on php-src master, this does seem to be the case in the 
majority of tests:

- var_export appears 703 times in 136 different *.phpt files (0.8% of files)
- print_r appears 827 times in 342 different *.phpt files (2.1% of files)
- var_dump appears 33503 times in 9599 different *.phpt files (59.7% of 
files)

So if we want to improve anything for that use case, we need to improve 
or replace var_dump, not var_export.


> - You need to copy the output into a codebase that's following a modern coding style guideline such as modern coding guidelines such as PSR-2. It also saves time if you don't have to remove array keys of lists and convert array() to [].


Trying to match any particular coding style seems rather outside the 
remit of a built-in function - do we need flags for tabs vs spaces, 
trailing commas, etc, etc? Surely it's simpler for users to take the 
existing var_export format and use their IDE or dev scripts to re-format 
it to taste.


Regards,

-- 
Rowan Tommins
[IMSoP]