[Debug] Symfony debug extension #10500

wants to merge 2 commits into

5 participants

Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets none
License MIT
Doc PR none

Add a symfony_zval_info($key, $array, $options = 0) function in a PHP extension written in C, that:

  • exposes zval_hash/refcount, allowing efficient exploration of arbitrary structure in PHP,
  • does work with references, preventing memory copying.

Please see the provided README for more info.

@cordoval cordoval commented on an outdated diff Mar 20, 2014
@@ -0,0 +1,21 @@
+$br = (php_sapi_name() == "cli")? "":"<br>";
cordoval added a line comment Mar 20, 2014

missing headers?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@jpauli jpauli referenced this pull request Mar 20, 2014

Symfony debug extension #10498

Symfony member

What's the relation to symfony?


The first short term use of this function is porting https://github.com/nicolas-grekas/Patchwork-Dumper to Symfony Debug component. With a target for enhancing the debug toolbar. Patchwork Dumper relies on an algorithm that allows exploring soft and hard references in arbitrary PHP structures. But PHP has no primitive to make this happen easily (== fast and memory efficient).
With this function, we add this missing simple primitive.
We also have other ideas with Julien to add more debug functions in this extension, that could lead to better debugging of memory leaks for example.

Symfony member

Given that such extension does not have any PHP counter-part, I find it weird to include it in the same repo than the PHP code while it requires a separate installation process (for Twig, the same feature is provided without the extension and the algorithms must stay in sync, so it is fine to have it in the repo).

Thus, the function is not even specific to Symfony. So IMO, it should be maintained in a separate repo (or even contributed to XDebug if possible, to have a single debugging extension instead of 2).
Btw, how does this function relate to xdebug_debug_zval ?

Symfony member

I also don't really think it belongs into symfony since it's not symfony specific.


We've been told to merge it here by @fabpot , so let's wait for his answer, so that he will clarify all this. Thx.


I didn't explain well: the dumper is already implemented in pure PHP. That won't change. And when this extension is enabled, it could be used to gain a LOT of performance. This compares to the twig extension on this point: not required, but you gain perf. when enabled.

Does it belong to Symfony? What is Symfony? It's not a full stack framework. We are talking here of the Debug component. Symfony is dedicated to give powerful tools to PHP developers. A debug extension, that hooks into the PHP engine to give more information to devs is a very good thing.

For your question about xdebug_debug_zval, it's different in many way: It gives new information that is not available in PHP (zval_hash). That is of premium use for a dumper. Moreover, it is not targeted at one specific use (it does no output but returns an array). That means that even if I personally plan to use it for dumping efficiently, anyone else can come with an other use case, or a better dumper, and build something cool upon it. That! is powerfulness :)

Symfony member


Symfony member

@nicolas-grekas I don't disagree about having it as part of Symfony (I suggested contributing it to XDebug to have a single debugging extension needing to be installed, but this is not a blocker for me). But IMO, the C extension should probably live inside its own repo


Replaced by #10640

@nicolas-grekas nicolas-grekas deleted the nicolas-grekas:debug_ext branch Apr 5, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment