php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #73811 Add var_dump-like function to return output as string
Submitted: 2016-12-25 14:09 UTC Modified: 2016-12-28 13:26 UTC
From: pjvleeuwen at gmail dot com Assigned:
Status: Wont fix Package: Variables related
PHP Version: 7.1.0 OS: n/a
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2016-12-25 14:09 UTC] pjvleeuwen at gmail dot com
Description:
------------
Please allow var_dump to return the output as a string instead of printing. Basically adding the same $return parameter and behavior as for var_export and print_r. Adding this parameter would be fully backwards compatible.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-12-25 14:28 UTC] requinix@php.net
-Summary: allow var_dump to return output as string +Summary: Add var_dump-like function to return output as string -Package: SPL related +Package: Variables related
 [2016-12-25 14:28 UTC] requinix@php.net
Adding $return would not work: how would var_dump() know that you aren't trying to dump a bool(true) but passing a special argument?

This would have to be a new function, eg. var_dump_r or var_rdump.
 [2016-12-25 21:38 UTC] pjvleeuwen at gmail dot com
You are right, an oversight. Thanks.

A new function (I would find the var_dump_r suggestion the most consistent) would indeed be a possibility. But it seems that adding yet another function might not be very scaleable, these three already feel quite ad hoc invented, while they are quite similar: represent some variable as text.

I would propose to add a 3rd $format argument (optional) to var_export (which I think has to most concise name):
PRINTR_PARSABLE - default option, current output format of var_export
PRINTR_HUMAN - current output format of print_r
PRINTR_TYPED - current output format of var_dump

The main benefit with only these 3 constants would be allowing var_dump output format to be returned as string in a consistent way. print_r would become redundant.

This would allow other formats to be added without a further need to be creative with similar sounding function names.
 [2016-12-25 21:46 UTC] requinix@php.net
You say "other formats"...

print_r and var_dump are debugging functions. They shouldn't be used for "practical" purposes like serialization or storage so there isn't much room for improvement - however since print_r can output or return a string, it makes sense for there to be output and return-a-string versions of var_dump.

But other formats? What for? If either function doesn't provide specific information that's would assist debugging then it should be added, but neither of them are really appropriate for anything other than a human to read.
 [2016-12-25 23:52 UTC] yohgaki@php.net
-Status: Open +Status: Wont fix
 [2016-12-25 23:52 UTC] yohgaki@php.net
Number of var_dump() args are variable, so we cannot add flag for returning string.
http://php.net/manual/en/function.var-dump.php

Use output buffer if you need to get output as string.

ob_start();
var_dump($foo);
$dump = ob_get_clean();
 [2016-12-25 23:55 UTC] yohgaki@php.net
Oops, I didn't notice comments.
Anyway, writing your own var_dump() with output buffer should be easy.
 [2016-12-26 07:12 UTC] pjvleeuwen at gmail dot com
Thanks for documenting the workaround. Of course I could start writing my own version of this standard method, but for me this ticket is about improving the offering to all PHP users.

Regardless whether we ever need other formats I think the proposal above would harmonize 3 very similar functions in one without breaking backwards compatibility. That on top adding a feature in SPL that prevents people having to write their own version of var_dump.

Since this ticket was closed before even reading the proposal in the comments I would like to ask to put it back to Open, allowing to consider this proposal:

I would propose to add a 3rd $format argument (optional) to var_export (which I think has to most concise name):
EXPORT_PARSABLE - default option, current output format of var_export
EXPORT_HUMAN - current output format of print_r
EXPORT_TYPED - current output format of var_dump
 [2016-12-28 13:26 UTC] cmb@php.net
> I would propose to add a 3rd $format argument (optional) to
> var_export (which I think has to most concise name):
> EXPORT_PARSABLE - default option, current output format of var_export
> EXPORT_HUMAN - current output format of print_r
> EXPORT_TYPED - current output format of var_dump

That would require an RFC, anyway. <https://wiki.php.net/rfc/howto>
explains how that is done.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Sun Nov 29 05:01:23 2020 UTC