Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112946
To: internals@lists.php.net
References: <DM6PR07MB66189CC60F94349200D0D02BF9A40@DM6PR07MB6618.namprd07.prod.outlook.com>
 <22e7ebcf-3f98-ff74-8d84-d2b50cda44b7@gmail.com>
 <1DF0F205-30A4-4FA3-8A58-703BAC6AD732@gmail.com>
Message-ID: <18afe2ed-0802-8f76-b094-64d5ff8cf37f@gmail.com>
Date: Wed, 20 Jan 2021 21:44:30 +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: <1DF0F205-30A4-4FA3-8A58-703BAC6AD732@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Proposal: short_var_export($value, bool $return=false,
 int $flags=0)
From: rowan.collins@gmail.com (Rowan Tommins)

On 20/01/2021 20:21, Claude Pache wrote:
> Or `short_var_export()` could just reuse the existing `__debugInfo()` 
> magic method (which is already used by both `var_dump()` and 
> `print_r`, but not by `var_export()`). The programmer would just need 
> to make sure that `__set_state()` can consume the array produced by 
> `__debugInfo()`.


This is an interesting question to explore, but I don't follow how this 
relates to my previous e-mail. I'm saying that having print_r, var_dump, 
var_export, and var_export_short (or whatever we call it) all in one 
language is more confusing than helpful.


Regards,

-- 
Rowan Tommins
[IMSoP]