Hello everyone,
this is a proposal to add new function to PHP core: spl_object_id()
The story:
Recently I was debugging some larger libraries and sorely missed a function
that would return an object ID. A function called spl_object_hash() exists,
but it returns identical hashes for equal objects. You need object ID to be
really sure if two references are indeed the same object or two identical
objects.
Most of the meat is described in this StackOverflow thread:
http://stackoverflow.com/questions/2872366/get-instance-id-of-an-object-in-php
The OP proposes OB+var_dump() magic, which works if objects are small.
Unfortunatelly I was hitting "Allowed memory exceeded".
The second answer, given by Gustavo Lopes, describes how to create an
extension for this, which provides new function, named spl_object_id(). I
believe this function should be included in PHP core.
Sample implementation (not tested):
/* {{{ proto string spl_object_id(object obj)
Return id for given object */
PHP_FUNCTION(spl_object_id)
{
zval *obj;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "o", &obj) == FAILURE)
{
return;
}
RETURN_LONG(Z_OBJ_HANDLE_P(obj));
}
/* }}} */
Two questions:
- Do you think this function should be included in PHP core?
- If so, what should this function be called? I am undecided between
spl_object_id() and spl_object_handle() and corresponding get_...()
variants.
Ad 2. I lean towards ..._id() as ..._handle() suggests that you can do
something with that handle (think "open file handle", etc).
What is your opinion about this?
Tnx,
b.
Won't $obj1 === $obj2 work for you ?
Hello everyone,
this is a proposal to add new function to PHP core: spl_object_id()
The story:
Recently I was debugging some larger libraries and sorely missed a function
that would return an object ID. A function calledspl_object_hash()exists,
but it returns identical hashes for equal objects. You need object ID to be
really sure if two references are indeed the same object or two identical
objects.Most of the meat is described in this StackOverflow thread:
http://stackoverflow.com/questions/2872366/get-instance-id-of-an-object-in-php
The OP proposes OB+var_dump() magic, which works if objects are small.
Unfortunatelly I was hitting "Allowed memory exceeded".The second answer, given by Gustavo Lopes, describes how to create an
extension for this, which provides new function, named spl_object_id(). I
believe this function should be included in PHP core.Sample implementation (not tested):
/* {{{ proto string spl_object_id(object obj)
Return id for given object */
PHP_FUNCTION(spl_object_id)
{
zval *obj;if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "o", &obj) == FAILURE)
{
return;
}
RETURN_LONG(Z_OBJ_HANDLE_P(obj));
}
/* }}} */Two questions:
- Do you think this function should be included in PHP core?
- If so, what should this function be called? I am undecided between
spl_object_id() and spl_object_handle() and corresponding get_...()
variants.Ad 2. I lean towards ..._id() as ..._handle() suggests that you can do
something with that handle (think "open file handle", etc).What is your opinion about this?
Tnx,
b.
Won't
$obj1 === $obj2work for you ?
This works if you have two objects which are easily accessible in the same
scope.
Not that it can not be done this way, but it may require jumping through
hoops to get two object references into the common scope where you can
compare them.
By having a method to retrieve and display object id/handle, one can easily
compare identity of objects in various scopes, and/or at various execution
times/points.
Think of it like this:
- in file bootstrap.php I see this object initialized and passed somewhere
- in file view.phtml I receive the object of the same type, but how can I
be sure that this object was not re-initialized somewhere in between?
b.
Am 28.11.2014 20:23 schrieb "Bostjan Skufca" bostjan@a2o.si:
Won't
$obj1 === $obj2work for you ?
Think of it like this:
- in file bootstrap.php I see this object initialized and passed somewhere
- in file view.phtml I receive the object of the same type, but how can I
be sure that this object was not re-initialized somewhere in between?
Why would you care about that?
You would need to stash away that "identity information" somewhere, in
bootstrap.php, and refer to that in view.phtml, right? Why can't you just
stash away the object itself? Then you won't even have a need to "receive
the object" in view.phtml.
I really don't get it. What are you trying to do there that you cannot do
with storing the object (reference) itself?
best regards
Patrick
I really don't get it. What are you trying to do there that you cannot do
with storing the object (reference) itself?
I probably provided a poor explanation.
All this was meant as a convenience method for quick debugging. I just
needed to quickly check if multiple object references which occur at
different points of code execution, actually point to the same object.
The question was: was this object reinitialized somewhere in between.
Consider this execution flow:
|Black Magic| ---> |Code of interest #1| ---> |Black Magi|c ---> |Code
of interest #2| ---> ...
"Black magic" represents larger chunks of OO code that is not really
one's concern at the moment.
The quickest way to verify if object refs at all "Code of interest"
points (#1, #2, #3... #n) include the same object is to dump the
object IDs somewhere (file for example) and visually inspect them. I
am not saying it can not be done otherwise (storing objects in some
registry, etc), but I am talking about quick and convenient way of
doing it.
b.
Won't
$obj1 === $obj2work for you ?This works if you have two objects which are easily accessible in the same
scope.Not that it can not be done this way, but it may require jumping through
hoops to get two object references into the common scope where you can
compare them.
If you can get their hashes to the same place, you can get the object
to the same place.
Big -1 from me.
Am 28.11.2014 um 21:21 schrieb Levi Morrison:
Won't
$obj1 === $obj2work for you ?This works if you have two objects which are easily accessible in the same
scope.Not that it can not be done this way, but it may require jumping through
hoops to get two object references into the common scope where you can
compare them.
If you can get their hashes to the same place, you can get the object
to the same place.Big -1 from me.
This given example sounds wired to me, too.
But to have a unique ID for objects sound like a very good idea and
would solve the object as array key issue.
I'm sure it's not as simple as the function prototype explained in this
thread previously.
But to have a unique ID for objects sound like a very good idea and
would solve the object as array key issue.
I'm sure it's not as simple as the function prototype explained in
this thread previously.
Indeed. Fortunately, we already have one: it's called spl_object_hash()
If the current limitation of handles being potentially reused (which
would also affect this proposal) can be solved, then it can be done
there without creating a new function, as far as I can see.
For quick comparison, here's the key line of the proposed implementation:
RETURN_LONG(Z_OBJ_HANDLE_P(obj));
And here's the key lines of the spl_object_hash() implementation [1]:
SPL_G(hash_mask_handle) = (intptr_t)(php_mt_rand(TSRMLS_C) >> 1);
SPL_G(hash_mask_handlers) = (intptr_t)(php_mt_rand(TSRMLS_C) >> 1);
...
hash_handle = SPL_G(hash_mask_handle)^(intptr_t)Z_OBJ_HANDLE_P(obj);
hash_handlers = SPL_G(hash_mask_handlers)^(intptr_t)Z_OBJ_HT_P(obj);
return strpprintf(32, "%016lx%016lx", hash_handle, hash_handlers);
So, the existing function varies based on the object's "handle" (the
part the simple implementation would return unhashed), its "handlers",
plus some per-thread randomness.
[1] http://lxr.php.net/xref/PHP_TRUNK/ext/spl/php_spl.c#756
--
Rowan Collins
[IMSoP]
Hello everyone,
this is a proposal to add new function to PHP core: spl_object_id()
The story:
Recently I was debugging some larger libraries and sorely missed a function
that would return an object ID. A function calledspl_object_hash()exists,
but it returns identical hashes for equal objects. You need object ID to be
really sure if two references are indeed the same object or two identical
objects.Most of the meat is described in this StackOverflow thread:
http://stackoverflow.com/questions/2872366/get-instance-id-of-an-object-in-phpThe OP proposes OB+var_dump() magic, which works if objects are small.
Unfortunatelly I was hitting "Allowed memory exceeded".The second answer, given by Gustavo Lopes, describes how to create an
extension for this, which provides new function, named spl_object_id(). I
believe this function should be included in PHP core.Sample implementation (not tested):
/* {{{ proto string spl_object_id(object obj)
Return id for given object */
PHP_FUNCTION(spl_object_id)
{
zval *obj;if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "o", &obj) == FAILURE)
{
return;
}
RETURN_LONG(Z_OBJ_HANDLE_P(obj));
}
/* }}} */Two questions:
- Do you think this function should be included in PHP core?
- If so, what should this function be called? I am undecided between
spl_object_id() and spl_object_handle() and corresponding get_...()
variants.Ad 2. I lean towards ..._id() as ..._handle() suggests that you can do
something with that handle (think "open file handle", etc).What is your opinion about this?
Tnx,
b.
Morning,
I don't think so, there is talk of removing object handles in 7.
Even if we intended to keep object handles, this leaks implementation
details that we don't really want leaked.
Cheers
Joe
I don't think so, there is talk of removing object handles in 7.
Could you point me to a discussion about this? Tnx.
Even if we intended to keep object handles, this leaks implementationdetails that we don't really want leaked.
I understand your concern, but I think being able to uniquely identify
objects should be PHP feature and not a leaked implementation detail.
Looking into other languages:
- ruby has obj.object_id
- python has id(obj) which is functionally equal to
spl_object_hash(),
I can not find anything about unique ID for now - perl has Object::ID module
b.
2014-11-28 2:13 GMT+01:00 Bostjan Skufca bostjan@a2o.si:
Hello everyone,
this is a proposal to add new function to PHP core: spl_object_id()
The story:
Recently I was debugging some larger libraries and sorely missed a function
that would return an object ID. A function calledspl_object_hash()exists,
but it returns identical hashes for equal objects.
It returns unique IDs for existing objects. A hash is only reused only when
the corresponding object was removed by the GC earlier.
So actually asking me it makes more sense to "fix" the behaviour of
spl_object_hash(),
You need object ID to be
really sure if two references are indeed the same object or two identical
objects.Most of the meat is described in this StackOverflow thread:
http://stackoverflow.com/questions/2872366/get-instance-id-of-an-object-in-php
The OP proposes OB+var_dump() magic, which works if objects are small.
Unfortunatelly I was hitting "Allowed memory exceeded".The second answer, given by Gustavo Lopes, describes how to create an
extension for this, which provides new function, named spl_object_id(). I
believe this function should be included in PHP core.Sample implementation (not tested):
/* {{{ proto string spl_object_id(object obj)
Return id for given object */
PHP_FUNCTION(spl_object_id)
{
zval *obj;if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "o", &obj) == FAILURE)
{
return;
}
RETURN_LONG(Z_OBJ_HANDLE_P(obj));
}
/* }}} */Two questions:
- Do you think this function should be included in PHP core?
- If so, what should this function be called? I am undecided between
spl_object_id() and spl_object_handle() and corresponding get_...()
variants.Ad 2. I lean towards ..._id() as ..._handle() suggests that you can do
something with that handle (think "open file handle", etc).What is your opinion about this?
Tnx,
b.
On Fri, Nov 28, 2014 at 2:14 PM, Sebastian Krebs krebs.seb@gmail.com
wrote:
2014-11-28 2:13 GMT+01:00 Bostjan Skufca bostjan@a2o.si:
Hello everyone,
this is a proposal to add new function to PHP core: spl_object_id()
The story:
Recently I was debugging some larger libraries and sorely missed a
function
that would return an object ID. A function calledspl_object_hash()
exists,
but it returns identical hashes for equal objects.It returns unique IDs for existing objects. A hash is only reused only when
the corresponding object was removed by the GC earlier.
So actually asking me it makes more sense to "fix" the behaviour of
spl_object_hash(),
yeah, the more I think about it the more I feel that the current
implementation is just a landmine.
you shouldn't store the return value and compare it later, even inside of
the same request, because you could have collision if the object which the
hash belongs gets freed before you compare.
so basically the only safe usage would be the one where you have the two
objects which you want to compare right away, but in that case, you could
also just === them.
I also used spl_object_hash() in the past when traversing/custom
serializing object structures which can have infinite recursions between
objects, but even that could be simply solved by storing the already
traversed objects in an array (as assigning the objects into another
variable doesn't have much overhead) and checking with in_array.
would be nice hearing from others for what else are they using
spl_object_hash() for.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Friday 28 November 2014 14:51:55 Ferenc Kovacs wrote:
I also used
spl_object_hash()in the past when traversing/custom
serializing object structures which can have infinite recursions
between
objects, but even that could be simply solved by storing the already
traversed objects in an array (as assigning the objects into another
variable doesn't have much overhead) and checking with in_array.
Checking with in_array is O(N) while an array keyed on
spl_object_hash() with the values being the objects, is stable wrt. hash
string vs. object lifetime, and is O(1) on checking for key existence.
The performance difference will become apparent when you have more
than a handful of objects there.
BTW, the two or three places where I use spl_object_hash(), in this way,
are exactly your use case: as an "already visited" cache during traversal
of somewhat arbitrary input structure (logging / dumping).
best regards
Patrick
On Friday 28 November 2014 14:51:55 Ferenc Kovacs wrote:
I also used
spl_object_hash()in the past when traversing/customserializing object structures which can have infinite recursions between
objects, but even that could be simply solved by storing the already
traversed objects in an array (as assigning the objects into another
variable doesn't have much overhead) and checking with in_array.
Checking with in_array is O(N) while an array keyed on
spl_object_hash()
with the values being the objects, is stable wrt. hash string vs. object
lifetime, and is O(1) on checking for key existence.The performance difference will become apparent when you have more than a
handful of objects there.
yeah, if you already have the hashmap ready, then
calling array_key_exists(spl_object_hash($needle), $haystack) will be much
cheaper.
but don't forget that for that you have to build the hashmap, eg. you have
to call spl_object_hash() for each element, so you can't ignore the cost of
that when comparing to the simple in_array solution.
from a quick test using spl_object_hash seems to be the slower with big
number of elements in haystack.
<?php
$iteration = (int)$argv[1];
$needle = new StdClass;
$haystack = array();
for ($i=0;$i<$iteration;$i++) {
$haystack[] = new StdClass;
}
$haystack[] = $needle;
var_dump(in_array($needle, $haystack, true));
vs
<?php
$iteration = (int)$argv[1];
$needle = new StdClass;
$key = spl_object_hash($needle);
$haystack = array();
for ($i=0;$i<$iteration;$i++) {
$object = new StdClass;
$haystack[spl_object_hash($object)] = $object;
}
$haystack[$key] = $needle;
var_dump(array_key_exists($key, $haystack));
BTW, the two or three places where I use
spl_object_hash(), in this way,
are exactly your use case: as an "already visited" cache during traversal
of somewhat arbitrary input structure (logging / dumping).
thanks for the feedback!
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Am 28.11.2014 15:46 schrieb "Ferenc Kovacs" tyra3l@gmail.com:
from a quick test using spl_object_hash seems to be the slower with big
number of elements in haystack.
Your test only does the is-it-known test once. For an already-visited-set
use case the test will run once for each visited element, and will usually
fail, too, thus running the whole already built haystack at each point from
front to end with in_array - overall N*(N/2) test + Nsimple-array-append
for the in_array approach, vs. N test + Nspl_object_hash-append.
best regards
Patrick
Am 28.11.2014 15:46 schrieb "Ferenc Kovacs" tyra3l@gmail.com:
from a quick test using spl_object_hash seems to be the slower with big
number of elements in haystack.Your test only does the is-it-known test once. For an already-visited-set
use case the test will run once for each visited element, and will usually
fail, too, thus running the whole already built haystack at each point from
front to end with in_array - overall N*(N/2) test + Nsimple-array-append
for the in_array approach, vs. N test + Nspl_object_hash-append.best regards
Patrick
you are right, the actual visited set pattern is much more favorable for
the hash lookups.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Ferenc Kovacs wrote on 28/11/2014 13:51:
On Fri, Nov 28, 2014 at 2:14 PM, Sebastian Krebs krebs.seb@gmail.com
wrote:2014-11-28 2:13 GMT+01:00 Bostjan Skufca bostjan@a2o.si:
Hello everyone,
this is a proposal to add new function to PHP core: spl_object_id()
The story:
Recently I was debugging some larger libraries and sorely missed a
function
that would return an object ID. A function calledspl_object_hash()
exists,
but it returns identical hashes for equal objects.It returns unique IDs for existing objects. A hash is only reused only when
the corresponding object was removed by the GC earlier.
So actually asking me it makes more sense to "fix" the behaviour of
spl_object_hash(),yeah, the more I think about it the more I feel that the current
implementation is just a landmine.
Is there any BC implication of changing the implementation? Or is it
just that we don't know what the alternative should be?
Looking at the implementation of spl_object_hash() [1] it already uses
Z_OBJ_HANDLE_P(obj) as part of the output, so presumably that isn't
enough to guarantee uniqueness anyway? (Which then leads to the question
of what the advantage of an spl_object_id() function would actually be,
if it's less unique than spl_object_hash())
[1] http://lxr.php.net/xref/PHP_TRUNK/ext/spl/php_spl.c#756
Rowan Collins
[IMSoP]
A function called
spl_object_hash()exists,
but it returns identical hashes for equal objects.
In case it's been lost in the noise, no it doesn't.
From http://php.net/spl_object_hash
Return Values
A string that is unique for each currently existing object and is
always the same for each object.
--
Rowan Collins
[IMSoP]
A function called
spl_object_hash()exists,
but it returns identical hashes for equal objects.In case it's been lost in the noise, no it doesn't.
Ouch. I am terribly sorry about this mistake, it really does not.
However, having word "hash" in the function name suggests that
returned hash is generated by the object's contents, too. I just
noticed that the first comment explains that this is not the case,
which I confirmed with additional testing.
To quote a part of first sentence of Wikipedia on "Hash function":
"...with slight differences in input data producing very big
differences in output data."
So, to sum it up: spl_object_hash indeed does what I initially
required, but I was mislead by the "hash" word in its name, and the
environment where I was trying to use it (unable to bring two object
references in the same place easily).
But I would maybe suggest changing the name to spl_object_id (and
keeping ..._hash alias for backward compatibility).
b.
A function called
spl_object_hash()exists,
but it returns identical hashes for equal objects.
In case it's been lost in the noise, no it doesn't.
Ouch. I am terribly sorry about this mistake, it really does not.However, having word "hash" in the function name suggests that
returned hash is generated by the object's contents, too. I just
noticed that the first comment explains that this is not the case,
which I confirmed with additional testing.To quote a part of first sentence of Wikipedia on "Hash function":
"...with slight differences in input data producing very big
differences in output data."So, to sum it up: spl_object_hash indeed does what I initially
required, but I was mislead by the "hash" word in its name, and the
environment where I was trying to use it (unable to bring two object
references in the same place easily).But I would maybe suggest changing the name to spl_object_id (and
keeping ..._hash alias for backward compatibility).
I can see the confusion, but the output is more like a hash than an ID -
it's just that the input of the hashing is the object's immutable
metadata, not its current internal state. Specifically, it's an
arbitrary value which has no meaning beyond being unique for each input,
and easily comparable between outputs.
That said, it does do rather poorly on the "small difference in input,
large difference in output" stakes; it could do with being run through
something like MD5 to make it more well distributed, and easier for
debugging by human eyes. Of course, you can always just do that in
userland with md5(spl_object_hash($foo))
Regards,
--
Rowan Collins
[IMSoP]
Hi
this is a proposal to add new function to PHP core: spl_object_id()
IMHO this is a good idea: currently, var_dump has this super-power (and
super-useful) capability of outputting a number that ease recognizing
identical objects in dumps. This power should be transferred to userland
devs so they can build their own tools.
In fact, that's what I've done: since Symfony 2.6, you can dump using a
userland function that (IMHO again) is more powerful than var_dump:
http://symfony.com/doc/current/components/var_dumper/introduction.html
In order to get an object's id, I use a trick that works for now:
https://github.com/symfony/symfony/blob/2.6/src/Symfony/Component/VarDumper/Cloner/VarCloner.php#L258-L282
But I'd prefer replacing this trick by a dedicated function. So, with
Julien Pauli, we worked on such a function. Symfony 2.6 also embeds a PHP
extension that exposes more meta data about variables:
https://github.com/symfony/symfony/tree/2.6/src/Symfony/Component/Debug/Resources/ext
The function implemented in this extension is the root primitive that
enables building a feature-full dumper, without resorting to tricks in PHP.
Any interest in putting this in PHP core? Please feel free to do so, you
have my vote :)
Many thanks,
Nicolas
Nicolas Grekas wrote on 09/12/2014 09:31:
Hi
this is a proposal to add new function to PHP core: spl_object_id()
IMHO this is a good idea: currently, var_dump has this super-power (and
super-useful) capability of outputting a number that ease recognizing
identical objects in dumps. This power should be transferred to userland
devs so they can build their own tools.In fact, that's what I've done: since Symfony 2.6, you can dump using a
userland function that (IMHO again) is more powerful than var_dump:http://symfony.com/doc/current/components/var_dumper/introduction.html
In order to get an object's id, I use a trick that works for now:
https://github.com/symfony/symfony/blob/2.6/src/Symfony/Component/VarDumper/Cloner/VarCloner.php#L258-L282
This seems like a very elaborate piece of reverse engineering for very
little gain. If you just want to turn the result of spl_object_hash into
a consistent integer, just use whatever re-hashing you like. The exact
value of the "object handle" is not something you could ever do anything
with anyway, surely?
But I'd prefer replacing this trick by a dedicated function. So, with
Julien Pauli, we worked on such a function. Symfony 2.6 also embeds a PHP
extension that exposes more meta data about variables:
https://github.com/symfony/symfony/tree/2.6/src/Symfony/Component/Debug/Resources/extThe function implemented in this extension is the root primitive that
enables building a feature-full dumper, without resorting to tricks in PHP.
The more interesting part of this is the refcount - unlike
spl_object_hash(), which does its job just fine, debug_zval_dump() is
broken, because the documented use requires call-time pass-by-reference,
which is actually impossible in current versions of PHP. A replacement
would presumably need to hook in as a language construct rather than a
function, so that the function call itself doesn't mess up the refcount
and is_ref status of a ZVAL?
Regards,
Rowan Collins
[IMSoP]
Hi Rowan,
In order to get an object's id, I use a trick that works for now:
https://github.com/symfony/symfony/blob/2.6/src/Symfony/
Component/VarDumper/Cloner/VarCloner.php#L258-L282This seems like a very elaborate piece of reverse engineering
Right, and I made the claim for this being a trick :)
Still: the exact value is not what I'm most interested in you're right (but
it provides rought information about the number of objects currently
allocated which might be useful sometimes).
The gain is displaying a shortest possible number. I could rehash you're
right, but then I'll have collisions. Both arguments (short+unique number)
are relevant when debugging/dumping.
https://github.com/symfony/symfony/tree/2.6/src/Symfony/Component/Debug/Resources/ext
The more interesting part of this is the refcount
That, plus the fact that it returns the value (instead of writing it to
php://output)
but other returned values are also important, especially zval_hash and
zval_isref that allow efficient tracking of hard references.
Regards,
Nicolas
Nicolas Grekas wrote on 09/12/2014 14:39:
Hi Rowan,
In order to get an object's id, I use a trick that works for now: https://github.com/symfony/symfony/blob/2.6/src/Symfony/Component/VarDumper/Cloner/VarCloner.php#L258-L282 This seems like a very elaborate piece of reverse engineeringRight, and I made the claim for this being a trick :)
Still: the exact value is not what I'm most interested in you're right
(but it provides rought information about the number of objects
currently allocated which might be useful sometimes).The gain is displaying a shortest possible number. I could rehash
you're right, but then I'll have collisions. Both arguments
(short+unique number) are relevant when debugging/dumping.
Yes, I think a version of spl_object_hash that was more human-readable
would be a sensible move. IMHO, it would not be a BC break to completely
change the output, since the documentation makes no promises about it,
and reverse-engineered code like yours could just check PHP_VERSION.
https://github.com/symfony/symfony/tree/2.6/src/Symfony/Component/Debug/Resources/ext The more interesting part of this is the refcountThat, plus the fact that it returns the value (instead of writing it
to php://output)
but other returned values are also important, especially zval_hash and
zval_isref that allow efficient tracking of hard references.
Indeed. A non-function version of debug_zval_dump which could do this on
any variable would be even better (if I read it right, your function
only works on array members?)
--
Rowan Collins
[IMSoP]
t would not be a BC break to completely change the output
I agree! This could be as simple as removing the XOR for the first part of
the hash string (the first 16 chars) and expose the internal object's
handle there. This is already leaked by the output of var_dump so not a pb
imho. And BC is kept.
Indeed. A non-function version of debug_zval_dump which could do this on
any variable would be even better (if I read it right, your function only
works on array members?)
Not sure this is required: any variable can be put in an array for this
purpose thanks to get_defined_vars() and the (array) cast operator for
objects.
Indeed. A non-function version of debug_zval_dump which could do this
onany variable would be even better (if I read it right, your function
only
works on array members?)Not sure this is required: any variable can be put in an array for this
purpose thanks toget_defined_vars()and the (array) cast operator for
objects.
Sure, but like the function call, doing so just to send it to the debugger changes some of the information you're trying to see - it must increase the refcount, and in some situations could presumably mess up references too.
It would also be nice if you didn't have to think about such things, and could just use it on any variable reference, like you could isset().
--
Rowan Collins
[IMSoP]