Re: Proposal: short_var_export($value, bool $return=false, int $flags=0)
| From: | Sara Golemon | Date: | Wed, 20 Jan 2021 23:19:21 +0000 |
| Subject: | Re: Proposal: short_var_export($value, bool $return=false, int $flags=0) | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-112948@lists.php.net to get a copy of this message | ||
On Wed, Jan 20, 2021 at 3:44 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:
> 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.
>
>
IMO print_r/var_dump should be kept out of this discussion. Those are human
readable outputs for human consumption. var_export() is about a machine
readable output for recreating initial state within a runtime. The
requirements presented are wholly different.
-Sara