On 25/07/2015 12:49, Christoph Becker wrote:
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]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to