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
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.
EDIT
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' =>
object(test)[1]
public 'pub' =>
&object(test)[1]
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:
<?php
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' =>
object(test)[1]
public 'pub' =>
&object(test)[1]
'two' =>
object(test)[2]
public 'pub' =>
object(test)[1]
public 'pub' =>
&object(test)[1]
'three' =>
object(test)[3]
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.â
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.