The strange number after class name in xdebug var_dump()

I var_dump() an object, and it gives me this : object(Closure)[3]
What does the number 3 mean ?

Did you wrap your var_dump in <pre> tags or look at view-source?

AFAIK there should be more to it that that.

See the image below

I’m using xdebug var_dump()

Yes, I guess the indentation, such as it is, doesn’t help in recognition much.

Similar to how “length” is the number of characters in a string, and “size” is the number of key=>value pairs in an array, [#] is the number of property: value pairs in an object.

I guess they figure spelling out “properties” would be too much :wink:

1 Like

Except… it’s not. That Route object inside the array has at least 5 properties… but the number is 4.

I note that the numbers in the brackets are unique… Identifiers? Memory Address markers?

I note in the Xdebug Documentation Example they have an object referring to itself, and both are marked as 1

I took that to appear to be the case due to “wonky nesting” and an incomplete image, but maybe not.

Thanks StarLion.
After looking at that I’m even more confused now. Maybe something to do with “depth” or another setting?

The more i look at the documentation example, the more i think it’s a referencing scheme.

$t = new test;
$t->pub = $t;

So $t instantiates an object of type test. $t’s “pub” property is given the same object.

  'three' => $t,

So the ‘three’ element now references this object also.

  'three' => 
      public 'pub' => 
      private 'priv' => boolean true
      protected 'prot' => int 42

Theory: Because xdebug identifies that the object [1] identifies itself by reference (&object(test) [1]), it doesnt recurse into the object, despite only being at depth 2, because object [1] is already defined in the output.
(Course, it may also not be recursing into the object because it’s a reference and not an object itself…)

Terry, i’d be very interested in the complete dump of your variable, if you could in some way show us.

(I got bored. When i get bored, my fingers move after my brain.)

So i did some test running of my own on this, and i have to conclude that it is an object referencing scheme identifier.

I installed xdebug on my local WAMP stack and ran the following code:

class test {
    public $pub = false;
$t = new test;
$t->pub = $t;
$s = new test;
$s->pub = $t;
$r = new test;
$r->pub = 4;

$data = array(
    'one' => $t,
    'two' => $s,
    'three' => $r,
var_dump( $data );

Which resulted in:

array (size=3)
  'one' => 
      public 'pub' => 
  'two' => 
      public 'pub' => 
          public 'pub' => 
  'three' => 
      public 'pub' => int 4

All the $t references got set to [1] (it even recursed to point at the object inside the object in “two”, but only did so once… presumably a infinite-loop preventer)

EDIT: Adding a second class and instantiating another object of THAT class gave it a [4], so identifiers are not reused between class types.
EDITEDIT: Instantiating a an object OUTSIDE of $data before $t incremented all of the above numbers. So it’s using all objects instantiated by the script, not just those contained inside the var_dump’d variable, which is why we dont see a number 1 in Terry’s dump.

Thus, to answer the original question of “what does the [3] mean?” my answer is: “it’s the third object your script created.”

1 Like

I’ve never used xdebug with anything other than PHPStorm. PHPStorm nicely prints out property and method names when dumping objects via xdebug. var_dump isn’t necessary since code can be evaluated inline via PHPStorm. You simply right click on the IDE window and select “Evaluate Expression” which open a prompt which code be evaluated on the fly within the current context of the running script. I thought that feature was just about standard with all the xdebug IDE integrations. If not it is a huge value add for PHPStorm.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.