Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113300 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 42375 invoked from network); 27 Feb 2021 14:46:10 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 27 Feb 2021 14:46:10 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 57F811804D0 for ; Sat, 27 Feb 2021 06:35:41 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 27 Feb 2021 06:35:40 -0800 (PST) Received: by mail-ej1-f50.google.com with SMTP id g5so19758159ejt.2 for ; Sat, 27 Feb 2021 06:35:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jTh4EvAIMoLK3x40M7W1PxzbBjwwiy58BQ48rejmzXw=; b=cWL4WoqstaR6712nM9XDYtw5KIDq2j6EVTchcS0eNiWCypwh/YUfvmgZPgiGxizgPQ C/qLDwRCLGxMEQPD/RZkuzeF316otmmh87umi88OZi99yolZRSXk/SoYAp8AFt7A5cHu 677fd9xBqs7B04DJEdu6FEJ2Mk8LbKG6kV/1SP1YABIsF0K8aKwu9KxgLL+Ci7Zv9zL+ tgXpEfcvHx0REcGLn83HVzps9vKQkH1cqcmrNJKKQIWtvub+qlN047LpcgEb5r9uC5oW cDi2XuRxheivb1M/pNQd216y8WmdPic+LTR5M8N6rn80ZEetMI+gxPkUbYKua0ohTa/M HFmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jTh4EvAIMoLK3x40M7W1PxzbBjwwiy58BQ48rejmzXw=; b=srR7SWOnSLJaBsQemAHPjg+LUTQ7hfjfBV1P2eBJFOSm05A2mto2HPBM7OTuurEKcG 729aCA3vfkOETiRf7Cg1wt8K+AM8eg/M630pzLOzfqm+ZxHO4C63KSWpi66emLEgi8JJ eC7dWu+VXrdSGQbFoZDp4/+iR6FOtaJKPFno5LtuJm4/jHdrkUpCbVdheuRjiflYV0hr Fk0gtC7YCan612RHyMxjqLhgsmlwnH4fr8dqVuanBmYF84BJFLTRKLTdItwJKd/2k3e1 bkAkKTD+wSBVtihalIWPZTQNfhwxo9ZIMiWydCdX2/yKBupJy4Qh2KKE54gRV5lG8GUG RqpA== X-Gm-Message-State: AOAM531iHsDBm3oHBity0B4hxG8wzKvvmuuSUWDfafH0Tu9j1jVM2EIt UsobDuRDJs4KmORZbds0GJbUxlmdtnq+wwg9+CM= X-Google-Smtp-Source: ABdhPJxcYZ2uqTt6VhrPryzjv/TCI9R7vsFgR7FFhTLPxdgb7rEzfCNekapbfUsuBT+Q3c9JO0I6cjrErlm1d7rL0SM= X-Received: by 2002:a17:906:758:: with SMTP id z24mr7957928ejb.406.1614436536480; Sat, 27 Feb 2021 06:35:36 -0800 (PST) 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 14:35:25 +0000 Message-ID: To: Rowan Tommins Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000044f55f05bc524c2c" Subject: Re: [PHP-DEV] Deprecate debug_zval_dump? From: george.banyard@gmail.com ("G. P. B.") --00000000000044f55f05bc524c2c Content-Type: text/plain; charset="UTF-8" On Sat, 27 Feb 2021 at 14:00, Rowan Tommins 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] I would say adding this to the omnibus RFC and adding yourself as an author to it would be the easiest and simplest way. Except if people feel strongly about this function and want it to be voted separately (which I doubt). Best regards, George P. Banyard --00000000000044f55f05bc524c2c--