Hey:
I made a small PR about changes output of some types name in
debug_zval_dump, to make it behavior consistently with var_dump.
https://github.com/php/php-src/pull/1434
2 things are changed:
1. print int instead of long
2. print float instead of double.
RM and me are worrying about this will break some APPs unit tests
.. anyway, welting doesn't find any in github..
so, is there any objections to merge this into PHP7.0?
thanks
Xinchen Hui
@Laruence
http://www.laruence.com/
Hey:
I made a small PR about changes output of some types name indebug_zval_dump, to make it behavior consistently with var_dump.
https://github.com/php/php-src/pull/14342 things are changed: 1. print int instead of long 2. print float instead of double. RM and me are worrying about this will break some APPs unit tests.. anyway, welting doesn't find any in github..
so, is there any objections to merge this into PHP7.0?
Some consistencies changes in debug functions are fine imho.
Cheers,
Pierre
Hi!
I made a small PR about changes output of some types name indebug_zval_dump, to make it behavior consistently with var_dump.
https://github.com/php/php-src/pull/14342 things are changed: 1. print int instead of long 2. print float instead of double.
I think that's fine, it's a debug function, even says it in the name.
Also pretty deep into engine internals. So I don't think is it a
problem. Just add a note to UPGRADING.
--
Stas Malyshev
smalyshev@gmail.com
Hey:
I made a small PR about changes output of some types name indebug_zval_dump, to make it behavior consistently with var_dump.
https://github.com/php/php-src/pull/1434
That function desperately needs an updated manual page. The current one
recommends using call-time pass-by-reference (impossible since 5.4), and
the changes to zvals in PHP 7 make its behaviour completely different
from anything in PHP 5.
I've thought before that it might be best to simply deprecate it,
because the only information it gives is a highly questionable refcount
- though playing around, it seems to be less influenced by the act of
calling the function in PHP 7.
I'm also not convinced consistency with var_dump makes particular sense.
If anything, it should be extended to more accurately reflect the
internal representation, since that's it's claimed purpose.
For instance, an IS_REFERENCE zval could be shown as such, with a
separate refcount from the referenced value, so that you could follow
along with the examples in this blog post:
http://nikic.github.io/2015/05/05/Internal-value-representation-in-PHP-7-part-1
The current implementation just adds 1 to the target refcount, per this
experiment: http://3v4l.org/NejOM
Regards,
--
Rowan Collins
[IMSoP]
Rowan Collins wrote:
I made a small PR about changes output of some types name indebug_zval_dump, to make it behavior consistently with var_dump.
https://github.com/php/php-src/pull/1434That function desperately needs an updated manual page. The current one
recommends using call-time pass-by-reference (impossible since 5.4), and
the changes to zvals in PHP 7 make its behaviour completely different
from anything in PHP 5.
I agree that the manual page needs an update, but it seems that would
result in an even more lengthy explanation of the caveats due to the
different behavior under PHP 5 and PHP 7, respectively.
I've thought before that it might be best to simply deprecate it,
because the only information it gives is a highly questionable refcount
- though playing around, it seems to be less influenced by the act of
calling the function in PHP 7.
It seems to me that the basic issue of debug_zval_dump() is that it is a
function and not a language construct, so the refcounts are never "quite
right". The variadic nature of the function may add to the confusion,
see http://3v4l.org/UuRse.
For instance, an IS_REFERENCE zval could be shown as such, with a
separate refcount from the referenced value, so that you could follow
along with the examples in this blog post:
http://nikic.github.io/2015/05/05/Internal-value-representation-in-PHP-7-part-1
The current implementation just adds 1 to the target refcount, per this
experiment: http://3v4l.org/NejOM
Apparently, this has been done deliberately for compatibility reasons[1].
[1]
https://github.com/php/php-src/blob/php-7.0.0beta2/ext/standard/var.c#L357-L363
--
Christoph M. Becker
I agree that the manual page needs an update, but it seems that would
result in an even more lengthy explanation of the caveats due to the
different behavior under PHP 5 and PHP 7, respectively.
Well, the current manual page is invalid for any version of PHP which is
currently maintained, since 5.3 is EOL, and 5.4 raises a fatal error for
the first example.
That actually simplifies things a little bit, because you don't need all
the caveats about whether the variable is passed by reference or not,
that's can just be a historical footnote.
It seems to me that the basic issue of
debug_zval_dump()is that it is a
function and not a language construct, so the refcounts are never "quite
right".
Agreed.
The variadic nature of the function may add to the confusion,
see http://3v4l.org/UuRse.
Oh, lord, I didn't realise that was even possible!
For instance, an IS_REFERENCE zval could be shown as such, with a
separate refcount from the referenced value, so that you could follow
along with the examples in this blog post:
http://nikic.github.io/2015/05/05/Internal-value-representation-in-PHP-7-part-1
The current implementation just adds 1 to the target refcount, per this
experiment: http://3v4l.org/NejOM
Apparently, this has been done deliberately for compatibility reasons[1].[1]
https://github.com/php/php-src/blob/php-7.0.0beta2/ext/standard/var.c#L357-L363
Yeah, I spotted that comment, but compatibility with what, for what end?
The refcounts given aren't the same between PHP5 and PHP7, and the
current approach completely masks how many variables share an
IS_REFERENCE zval, because it only ever increments the count by 1.
If we're willing to change "long(42) refcount(1)" to "int(42)", then
even the format of the output clearly isn't sacred, so why not throw in
as much information as possible?
If we're not going to make any attempt at accuracy, then rather than
making cosmetic changes like "int" for "long", we should be adding an
E_DEPRECATED flag and leaving the function to die quietly.
Regards,
--
Rowan Collins
[IMSoP]
I agree that the manual page needs an update, but it seems that would
result in an even more lengthy explanation of the caveats due to the
different behavior under PHP 5 and PHP 7, respectively.Well, the current manual page is invalid for any version of PHP which is
currently maintained, since 5.3 is EOL, and 5.4 raises a fatal error for
the first example.That actually simplifies things a little bit, because you don't need all
the caveats about whether the variable is passed by reference or not,
that's can just be a historical footnote.
I agree, but even then it's a bit tricky, and the doc team seems to be
shorthanded currently. You may consider to give a helping hand. :)
If we're not going to make any attempt at accuracy, then rather than
making cosmetic changes like "int" for "long", we should be adding an
E_DEPRECATEDflag and leaving the function to die quietly.
I guess that might require an RFC.
--
Christoph M. Becker