Hi internals,
I'd like to gauge interest in adding two debugging functions to PHP core:
dd() and dump().
Background
Currently, developers rely on userland solutions like Laravel's dd() helper
or Symfony's VarDumper for enhanced debugging output. These tools are
widely adopted across the PHP ecosystem, suggesting strong demand for
better debugging primitives.
Proposal Overview- dd($var, ...$vars) - "dump and die" - outputs
formatted debug info and terminates execution
- dump($var, ...$vars) - outputs formatted debug info and continues
execution
Enhanced Features Over Existing Solutions- Native performance (no
userland overhead)
- Stack trace integration
- Memory usage reporting
- Execution timing (potentially)
- Better CLI formatting
*Why Core vs Userland?*Similar to how var_dump() provides basic
introspection, these functions would offer enhanced debugging capabilities
that benefit the entire ecosystem, not just framework users.
Implementation
I'm seeking collaboration with an experienced PHP core developer for the C
implementation. I can handle the RFC documentation, testing, etc. I have
experience with the Laravel/Symfony codebases.
*Before drafting a formal RFC, I'd appreciate feedback on:*1. General
appetite for enhanced debugging functions in core
2. Concerns about naming conflicts with existing userland helpers
3. Preferred feature scope
Thoughts?
Best regards,
Braunson Yager
Hi internals,
I'd like to gauge interest in adding two debugging functions to PHP
core: dd() and dump().Background
Currently, developers rely on userland solutions like Laravel's dd()
helper or Symfony's VarDumper for enhanced debugging output. These
tools are widely adopted across the PHP ecosystem, suggesting strong
demand for better debugging primitives.*Proposal Overview
*- dd($var, ...$vars) - "dump and die" - outputs formatted debug info
and terminates execution
- dump($var, ...$vars) - outputs formatted debug info and continues
execution*Enhanced Features Over Existing Solutions
*- Native performance (no userland overhead)
- Stack trace integration
- Memory usage reporting
- Execution timing (potentially)
- Better CLI formatting
*Why Core vs Userland?
*Similar to howvar_dump()provides basic introspection, these
functions would offer enhanced debugging capabilities that benefit the
entire ecosystem, not just framework users.Implementation
I'm seeking collaboration with an experienced PHP core developer for
the C implementation. I can handle the RFC documentation, testing, etc.
I have experience with the Laravel/Symfony codebases.*Before drafting a formal RFC, I'd appreciate feedback on:
*1. General appetite for enhanced debugging functions in core
2. Concerns about naming conflicts with existing userland helpers
3. Preferred feature scopeThoughts?
Best regards,
Braunson Yager
What exactly would dump() offer that's different/better than var_dump() already does today? Is it just a pretty-printed var_dump()? I don't really see a need for that.
--Larry Garfield
Le mar. 17 juin 2025 à 23:22, Larry Garfield larry@garfieldtech.com a
écrit :
Hi internals,
I'd like to gauge interest in adding two debugging functions to PHP
core: dd() and dump().Background
Currently, developers rely on userland solutions like Laravel's dd()
helper or Symfony's VarDumper for enhanced debugging output. These
tools are widely adopted across the PHP ecosystem, suggesting strong
demand for better debugging primitives.*Proposal Overview
*- dd($var, ...$vars) - "dump and die" - outputs formatted debug info
and terminates execution
- dump($var, ...$vars) - outputs formatted debug info and continues
execution*Enhanced Features Over Existing Solutions
*- Native performance (no userland overhead)
- Stack trace integration
- Memory usage reporting
- Execution timing (potentially)
- Better CLI formatting
*Why Core vs Userland?
*Similar to howvar_dump()provides basic introspection, these
functions would offer enhanced debugging capabilities that benefit the
entire ecosystem, not just framework users.Implementation
I'm seeking collaboration with an experienced PHP core developer for
the C implementation. I can handle the RFC documentation, testing, etc.
I have experience with the Laravel/Symfony codebases.*Before drafting a formal RFC, I'd appreciate feedback on:
*1. General appetite for enhanced debugging functions in core
2. Concerns about naming conflicts with existing userland helpers
3. Preferred feature scopeThoughts?
Best regards,
Braunson YagerWhat exactly would dump() offer that's different/better than
var_dump()
already does today? Is it just a pretty-printedvar_dump()? I don't
really see a need for that.--Larry Garfield
You should give dump() a try Larry, the benefits are self-explanatory ;)
About the proposal itself, as the author of Symfony's VarDumper (which is
also what Laravel uses under the hood), I'm definitely against it: having
the implementation in userland gives way more freedom to innovate on the
topic. Eg the number of casters is increasing version after version. Moving
this capability to php-src devs would kinda freeze everything. About
casters, it's an API provided by VarDumper to define per-type custom
representation logic. (There are more APIs provided by the component, and
used by third parties, eg PsySH). This aspect is ignored in the state of
the proposal.
About the naming dump/dd: while php-src could ignore that these functions
are widely used in userland, it should NOT, so the name should be different.
About the perf benefit, it's void to me: I'm not aware of anyone using
dumps in perf-critical code paths (the existing logic is already optimized
enough for all practical use cases.)
Then remains the will to make this work out of the box. I tend to agree
with this but the proposed solution has too many drawbacks (the main ones
listed above). It should be noted that symfony/var-dumper is a standalone
component, so one can trivially use it outside of any framework. Just
require it and you'll have the functions in any PHP apps.
Cheers,
Nicolas
While I understand that dd is a valid way of debugging PHP code, I don't
think we should encourage this. Users should be encouraged to learn how to
use proper debugger like XDebug. Plus PHP has plenty of dumping functions
already and I see no need for yet another one.
While I understand that dd is a valid way of debugging PHP code, I don't think we should encourage this. Users should be encouraged to learn how to use proper debugger like XDebug. Plus PHP has plenty of dumping functions already and I see no need for yet another one.
One could probably, easily, write a userland script that accomplished dd() via the XDebug protocol.
-Jeff
I'd like to gauge interest in adding two debugging functions to PHP core: dd() and dump().
Going out of your way to deliberately conflict with two very popular
userland function names is a bad idea.
*Enhanced Features Over Existing Solutions
*- Native performance (no userland overhead)
- Stack trace integration
- Memory usage reporting
- Execution timing (potentially)
- Better CLI formatting
All of these except the native performance already exist in userland
dumpers, and if you're counting xdebug's var_dump implementation then
you can scratch off native performance too.
*Why Core vs Userland?
*Similar to howvar_dump()provides basic introspection, these functions
would offer enhanced debugging capabilities that benefit the entire
ecosystem, not just framework users.
The primary feature of these dumpers isn't "Enhanced debugging
capabilities" it's pretty printing in HTML output. Color highlighting
and unfolding are nice bonuses but they aren't present in other
languages by default either (eg. Rust's Debug trait)
Xdebug var-dumper and kint are all framework agnostic (And neither
xdebug nor kint even require composer) so I don't understand how the
existing solutions "just" benefit framework users.
If anything I'd say core PHP already has too many dump functions:
print_r and var_dump do essentially the same thing, with minor
variations in debug_zval_dump and var_export
- Jonathan