Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127719
Precedence: bulk
MIME-Version: 1.0
References: <CALdAX-2vK10a3wqL5A39v3RJ8_wLLz2N7sZARUhuSQpUAV95Uw@mail.gmail.com>
 <f7cd7c14-f6f5-45e7-bb42-dab2c2aad6f0@app.fastmail.com>
In-Reply-To: <f7cd7c14-f6f5-45e7-bb42-dab2c2aad6f0@app.fastmail.com>
Date: Thu, 19 Jun 2025 14:39:19 +0200
Message-ID: <CAOWwgp=BtGGbrynbXsbrvquF1J0X7_uj-AvTe37399CgjfACwQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Pre-RFC: dd() and dump() functions for PHP core
To: Larry Garfield <larry@garfieldtech.com>, Braunson Yager <braunson@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000754d9d0637ec09e8"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000754d9d0637ec09e8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le mar. 17 juin 2025 =C3=A0 23:22, Larry Garfield <larry@garfieldtech.com> =
a
=C3=A9crit :

> 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

--000000000000754d9d0637ec09e8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><br></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=
=C2=A0mar. 17 juin 2025 =C3=A0=C2=A023:22, Larry Garfield &lt;<a href=3D"ma=
ilto:larry@garfieldtech.com" target=3D"_blank">larry@garfieldtech.com</a>&g=
t; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">On Tue, Jun 17, 2025, at 2:54 PM, Braunson Yager wrote:<br>
&gt; Hi internals,<br>
&gt;<br>
&gt; I&#39;d like to gauge interest in adding two debugging functions to PH=
P <br>
&gt; core: dd() and dump().<br>
&gt;<br>
&gt; *Background*<br>
&gt; Currently, developers rely on userland solutions like Laravel&#39;s dd=
() <br>
&gt; helper or Symfony&#39;s VarDumper for enhanced debugging output. These=
 <br>
&gt; tools are widely adopted across the PHP ecosystem, suggesting strong <=
br>
&gt; demand for better debugging primitives.<br>
&gt;<br>
&gt; *Proposal Overview<br>
&gt; *- dd($var, ...$vars) - &quot;dump and die&quot; - outputs formatted d=
ebug info <br>
&gt; and terminates execution<br>
&gt; - dump($var, ...$vars) - outputs formatted debug info and continues <b=
r>
&gt; execution<br>
&gt;<br>
&gt; *Enhanced Features Over Existing Solutions<br>
&gt; *- Native performance (no userland overhead)<br>
&gt; - Stack trace integration<br>
&gt; - Memory usage reporting<br>
&gt; - Execution timing (potentially)<br>
&gt; - Better CLI formatting<br>
&gt;<br>
&gt; *Why Core vs Userland?<br>
&gt; *Similar to how var_dump() provides basic introspection, these <br>
&gt; functions would offer enhanced debugging capabilities that benefit the=
 <br>
&gt; entire ecosystem, not just framework users.<br>
&gt;<br>
&gt; *Implementation*<br>
&gt; I&#39;m seeking collaboration with an experienced PHP core developer f=
or <br>
&gt; the C implementation. I can handle the RFC documentation, testing, etc=
. <br>
&gt; I have experience with the Laravel/Symfony codebases.<br>
&gt;<br>
&gt; *Before drafting a formal RFC, I&#39;d appreciate feedback on:<br>
&gt; *1. General appetite for enhanced debugging functions in core<br>
&gt; 2. Concerns about naming conflicts with existing userland helpers<br>
&gt; 3. Preferred feature scope<br>
&gt;<br>
&gt; Thoughts?<br>
&gt;<br>
&gt; Best regards,<br>
&gt; Braunson Yager<br>
<br>
What exactly would dump() offer that&#39;s different/better than var_dump()=
 already does today?=C2=A0 Is it just a pretty-printed var_dump()?=C2=A0 I =
don&#39;t really see a need for that.<br>
<br>
--Larry Garfield<br></blockquote><div><br></div><div><br></div><div>You sho=
uld give dump() a try Larry, the benefits are self-explanatory ;)</div><div=
><br></div><div>About the proposal itself, as the author of Symfony&#39;s V=
arDumper (which is also what Laravel uses under the hood), I&#39;m definite=
ly against it: having the implementation in userland gives way more freedom=
 to innovate on the topic. Eg the number of casters is increasing version a=
fter version. Moving this capability to php-src devs would kinda freeze eve=
rything. About casters, it&#39;s an API provided by VarDumper to define per=
-type custom representation logic. (There are more APIs provided by the com=
ponent, and used by third=C2=A0parties, eg PsySH). This aspect=C2=A0is igno=
red in the state of the=C2=A0proposal.</div><div><br></div><div>About the n=
aming dump/dd: while php-src could ignore that these functions are widely u=
sed in userland, it should NOT, so the name should be different.</div><div>=
<br></div><div>About the perf benefit, it&#39;s void to me: I&#39;m not awa=
re of anyone using dumps in perf-critical code paths (the existing logic is=
 already optimized enough for all practical use cases.)</div><div><br></div=
><div>Then remains the will to make this work out of the box. I tend to agr=
ee with this but the proposed solution has too many drawbacks (the main one=
s 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 requ=
ire it and you&#39;ll have the functions in any PHP apps.</div><div><br></d=
iv><div>Cheers,</div><div>Nicolas</div></div></div>
</div>
</div>

--000000000000754d9d0637ec09e8--