Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112973
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>
 <a810bb03-f32f-bde5-9c48-bd0dbb3b7149@gmail.com>
 <DM6PR07MB6618ABE1BB0EAC60442154B1F9BE9@DM6PR07MB6618.namprd07.prod.outlook.com>
Message-ID: <8e5d376c-0d7d-bf1b-bcca-3f8c4c737a22@gmail.com>
Date: Sun, 24 Jan 2021 18:47:10 +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: <DM6PR07MB6618ABE1BB0EAC60442154B1F9BE9@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 24/01/2021 16:17, tyson andre wrote:
> Even if a developer such as yourself doesn't need to generate code and don't expect to directly use it,
> **some of the applications and libraries they do use everyday would need to generate human and machine readable code.**


Sure, I believe you that there are use cases for a function that exports 
PHP code. I remain unconvinced that there is a need to have *two* 
functions for that purpose, which differ only in a few cosmetic details.


> **php-src phpt tests are for tests of php itself, which puts strict and atypical limitations on the test framework.**
> php-src's phpt test framework may represent needs of php-src and some pecl maintainers, not userland.


I'm not sure what point you're trying to make here. You were the one 
that mentioned php-src tests as a use case, so I looked to see what they 
currently use; the answer is *overwhelmingly* var_dump.


> Still, I would prefer using var_representation over var_dump in phpt for many use cases, especially with VAR_REPRESENTATION_SINGLE_LINE available.


In the previous thread, you agreed with Sara that var_dump should be 
"left out of this". Are you now saying that the new function *should* 
replace some uses of var_dump?

If that is an aim, should we look at what other differences there are 
between var_dump and var_export, and how we can make this new function 
cover more use cases?


> For a new developer, they may not have those features or plugins installed in their IDE,
> or may not be aware of the existence of the shortcut/command to invoke those features on a range.


I contend that a new developer would very rarely have any need to use 
this functionality at all.


> Additionally, scripts to reindent may not remove the `0 =>`, `1 =>`, etc,
> either not containing a php parser or assuming the user deliberately added those keys.


And maybe they'd be right not to - that's an unavoidable problem with 
any formatter, it won't be universal.

And that is why I'm sceptical of this function: it seems to be mostly a 
different set of arbitrary formatting decisions, which some people will 
prefer and some won't.

The only part that feels like fundamental value is escaping control 
characters, which could be added to var_dump and/or var_export and only 
affect that minority of a minority of usages which are relying on the 
exact output in cases where control characters are present.


Regards,

-- 
Rowan Tommins
[IMSoP]