Le mar. 17 juin 2025 à 23:22, Larry Garfield <la...@garfieldtech.com> a écrit :
> On Tue, Jun 17, 2025, at 2:54 PM, Braunson Yager wrote: > > 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 > > 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 > 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
