Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72285 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 55369 invoked from network); 5 Feb 2014 18:38:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Feb 2014 18:38:55 -0000 Authentication-Results: pb1.pair.com smtp.mail=php@golemon.com; spf=softfail; sender-id=softfail Authentication-Results: pb1.pair.com header.from=php@golemon.com; sender-id=softfail Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.192.181 as permitted sender) X-PHP-List-Original-Sender: php@golemon.com X-Host-Fingerprint: 209.85.192.181 mail-pd0-f181.google.com Received: from [209.85.192.181] ([209.85.192.181:47724] helo=mail-pd0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F7/33-38005-E3582F25 for ; Wed, 05 Feb 2014 13:38:55 -0500 Received: by mail-pd0-f181.google.com with SMTP id y10so681458pdj.26 for ; Wed, 05 Feb 2014 10:38:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tXeHKhkTU1fBPB4Ql4cmMnnoEo67dwH5Qp5W2ZF10VY=; b=l2NuUeq6PJOekLuk+b5fOt5dCuXDxyV3GnnPas1CPgIcD4gI+ypwg9uS/2krh7Bger Wd57cEro3c9KquF+C9+0EnaluCJ4EnOCN2jg/XjAiA11JUP9kLY8WbxNv/lrRXHyLloK WW+CEpJQUYjX0qf+rJ8LxodTKsIonScZzdnn3ic8rTjmUI/csmzji8GFRECqvcpqSkaR qm95LFqgHtX2+CFZbdHUURL9uFBT2GkdkdkqikdbbqoOzvIL4En6CZSU/ltgS2q434Ac uVWNrTCix9wht9l3bMyqbErBTCCi85LbcpPGBn38Qjo1KcOfDOhhXHMYokpkqI8FI93v XF+Q== X-Gm-Message-State: ALoCoQk73KKueVd1xuljUXm5N5qZNF8M2n/wFAYNoo7B3PomBwaEdHTrIgB16t0DFwVrMDFXccX/ MIME-Version: 1.0 X-Received: by 10.68.130.234 with SMTP id oh10mr4163803pbb.136.1391625532115; Wed, 05 Feb 2014 10:38:52 -0800 (PST) Sender: php@golemon.com Received: by 10.70.38.234 with HTTP; Wed, 5 Feb 2014 10:38:52 -0800 (PST) X-Originating-IP: [2620:0:1cfe:18:22c9:d0ff:fe87:295b] In-Reply-To: <52F0D36B.7010905@googlemail.com> References: <52F00437.7010903@googlemail.com> <52F005E6.6090702@googlemail.com> <52F0D36B.7010905@googlemail.com> Date: Wed, 5 Feb 2014 10:38:52 -0800 X-Google-Sender-Auth: BjTQ03lQKHX_GcTDauCiCMX7bOc Message-ID: To: Crypto Compress Cc: PHP Developers Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] [RFC] [VOTE] __debugInfo() From: pollita@php.net (Sara Golemon) On Tue, Feb 4, 2014 at 3:47 AM, Crypto Compress wrote: > 1. Can this hook be bypassed or disabled (global/temporary)? > e.g. real_var_dump(), ini setting, some other flag? > No. The existing get_debug_info behavior is always active and this RFC just lifts it up to the userspace level. Is there a specific use case for which you'd like that? I suppose you could always do: var_dump((array)$obj); and get the "real" prop info. In practice, an object would use this hook to provide better info, keeping implementation details out of the way (such as current uses in dom, sxe, mysqli, intl, and spl). > 2. What will be affected by this hook beside "var_dump"? > e.g. xdebug output, var_export, ... > var_dump() and print_r() are the only current uses of get_debug_info > 3. How would this behave (segfault?): > public function __debugInfo() { var_dump($this); return []; } > Badly (most likely timeout or memory limit E_ERROR). Don't do that. -Sara