Skip to content

Use serialize_precision for printing floats in var_dump() #5172

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 5 commits into from

Conversation

nikic
Copy link
Member

@nikic nikic commented Feb 12, 2020

var_dump() is debugging functionality, so it should print floating-point numbers accurately. We do this by switching to serialize_precision, which (by default) will print with as much precision as necessary to preserve the exact value of the float.

@nikic nikic force-pushed the var-dump-float branch 2 times, most recently from b1193aa to bfb433b Compare February 13, 2020 13:34
@claudepache
Copy link
Contributor

print_r() should also be modified, I think.

@hikari-no-yume
Copy link
Contributor

hikari-no-yume commented Feb 24, 2020

Thank you so much for doing this! I had worked on a patch for this but never finished it.

@nikic
Copy link
Member Author

nikic commented Feb 24, 2020

@claudepache Agreed, going to do that in a separate PR.

@hikari-no-yume Doing this kind of change has gotten a lot easier, thanks to the magic of bless_tests.php.

@hikari-no-yume
Copy link
Contributor

hikari-no-yume commented Feb 24, 2020

@claudepache @nikic Personally I think updating print_r() is a less obviously good idea. I just wrote my objections on internals, but will quote it here for convenience:

The one that gave me pause before and now is print_r(). In principle, it is just print but recursive (I assume that's whence the name comes), but unfortunately some people use it for debugging, so there might be a case for changing it. With that said, it's already a very bad choice for debugging due to other things ("1", 1, 1.0 and TRUE look the same, "0", 0.0, and 0 look the same, "", FALSE and NULL look the same…) that precision is the least of the developer's problems if they choose print_r(), and it's also not in the spirit of "print but recursive". So, it is probably unreasonable to change print_r() here. Maybe we should put a massive red "DO NOT USE THIS FOR DEBUGGING" warning on its documentation page…

@nikic
Copy link
Member Author

nikic commented Feb 24, 2020

@hikari-no-yume Yeah, just saw your mail. I agree with your assessment there, print_r should follow print semantics.

To be honest, I have no idea why that function even exists, it seems like a strictly inferior version of var_dump.

@hikari-no-yume
Copy link
Contributor

hikari-no-yume commented Feb 24, 2020

(Hope not to sidetrack things too much…) It seems like its niche is meant to be a way to “print” arrays and objects and have it be nicer for humans to read than var_dump. But if you're a developer then you have var_dump which is more informative for you, and if you're not a developer, a nicely-formatted table is probably clearer?

@php-pulls php-pulls closed this in a939805 Feb 25, 2020
@carusogabriel carusogabriel added this to the PHP 8.0 milestone May 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants