Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113318
MIME-Version: 1.0
References: <62243527-96EC-4234-AD50-EDB6333628D5@gmail.com>
In-Reply-To: <62243527-96EC-4234-AD50-EDB6333628D5@gmail.com>
Date: Sat, 27 Feb 2021 21:05:24 +0100
Message-ID: <CAF+90c_FAQn+Sz5jDiR_afUKn0vqVEKa=BiCwUxz14hqZOvxdw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000acb5f705bc56e8b3"
Subject: Re: [PHP-DEV] Deprecate debug_zval_dump?
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000acb5f705bc56e8b3
Content-Type: text/plain; charset="UTF-8"

On Sat, Feb 27, 2021 at 3:00 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> Hi all,
>
> I would like to propose we formally deprecate the function debug_zval_dump
> and remove it in PHP 9.0.
>
> This function is mostly similar to var_dump, with the additional ability
> to output the refcount of a variable. This has always been hard to
> interpret, but is now so complex as to be effectively useless:
>
> - Because it is implemented as a function taking a parameter in the normal
> way, the refcount has been modified by the time it is displayed. Depending
> on the value passed, this may include reference separation; in older
> versions of PHP, it was possible to affect this directly by forcing a
> pass-by-reference. The manual still discusses this, but it hasn't been
> possible since PHP 5.4. [1]
> - Since PHP 7, some types don't have a refcount at all, and references are
> represented by additional levels of zval. Without completely changing the
> output format, this information is impossible to convey accurately.
> - Optimisations affect the refcount in increasingly non-obvious ways. For
> instance, an array defined literally in the source code has an extra
> counted reference compared to one which has been modified at runtime. [2]
>
> Since this is a rather specialised piece of debugging information, not
> useful to the average user, I think it should be left to dedicated
> debugging tools. XDebug includes an equivalent function that takes a name
> and looks it up in the symbol table, avoiding some of the worst issues [3].
> I'm not familiar with PHPDBG, and it doesn't seem to have much
> documentation, but I assume it would be able to display this as well.
>
> I notice there's a draft for an omnibus "deprecations for PHP 8.1" RFC
> [4]. Should I add this there, or raise a separate RFC?
>
> Refs:
> 1: https://www.php.net/debug-zval-dump
> 2: https://3v4l.org/DVi3f
> 3: https://xdebug.org/docs/all_functions#xdebug_debug_zval
> 4: https://wiki.php.net/rfc/deprecations_php_8_1
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]


Can't say I've had much use for debug_zval_dump(), but I don't really see
the motivation for removing it either.

For PHP 8.1, I have already adjusted it to dump "interned" instead of a
refcount for interned strings and immutable arrays. If we additionally
change it to explicitly print reference wrappers, I believe that
debug_zval_dump() will produce a faithful representation.

Regards,
Nikita

--000000000000acb5f705bc56e8b3--