Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112975
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>
 <8e5d376c-0d7d-bf1b-bcca-3f8c4c737a22@gmail.com>
 <DM6PR07MB661862F3A7031039AAED674EF9BE9@DM6PR07MB6618.namprd07.prod.outlook.com>
Message-ID: <cd5b7420-6706-4d20-f0ee-9c42c718e1a3@gmail.com>
Date: Sun, 24 Jan 2021 21:41:06 +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: <DM6PR07MB661862F3A7031039AAED674EF9BE9@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 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]