Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72524 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64928 invoked from network); 12 Feb 2014 20:41:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Feb 2014 20:41:11 -0000 Authentication-Results: pb1.pair.com header.from=cryptocompress@googlemail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=cryptocompress@googlemail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.214.42 as permitted sender) X-PHP-List-Original-Sender: cryptocompress@googlemail.com X-Host-Fingerprint: 209.85.214.42 mail-bk0-f42.google.com Received: from [209.85.214.42] ([209.85.214.42:49668] helo=mail-bk0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id ED/08-19387-56CDBF25 for ; Wed, 12 Feb 2014 15:41:10 -0500 Received: by mail-bk0-f42.google.com with SMTP id 6so2814562bkj.15 for ; Wed, 12 Feb 2014 12:41:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=2ALKv1Mc9Xi7R46qu1BqSqinugPbITznhajBetqOnD4=; b=SCwzbyc54w06XMJB6BWnxV7Djbzoe8djld2+Es22+Q604PGH3HDmqZ8q3Rhn+sIeum RbClTx+slis5uKTXIJeEAJyin9bqFmY5mmjHKei/lLWyKj0S1/q1N+KLfA2Qp59omJaR Z8TSJnaprykvnQ58BiHPChH8DuTMHpOBHuBM07llzzV6Y3JxtIpusHdzaA9WNOheQ+DA 6ms1Q1M4UkXj5ynPh7faeckgek/eKJvkGOd94XPDwkLmBjbdWhFrDNix3POm74hItMDa saNAzOUW7e6HPdIMOv/pq/wjsMFe1BOxmc71h2izmxS3gZFOPqwV6Wmma7A5WR06nRpL F4jQ== X-Received: by 10.204.102.199 with SMTP id h7mr19295122bko.15.1392237667010; Wed, 12 Feb 2014 12:41:07 -0800 (PST) Received: from [192.168.1.115] (mnch-5d872b07.pool.mediaWays.net. [93.135.43.7]) by mx.google.com with ESMTPSA id f11sm18874304bkj.6.2014.02.12.12.41.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Feb 2014 12:41:05 -0800 (PST) Message-ID: <52FBDC4D.9020302@googlemail.com> Date: Wed, 12 Feb 2014 21:40:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Sara Golemon CC: PHP Developers Mailing List References: <52F00437.7010903@googlemail.com> <52FA71FE.8060808@googlemail.com> <1392151967.3990.11.camel@guybrush> <52FA90B3.5040205@googlemail.com> <1392153156.3990.13.camel@guybrush> <52FA99C4.5080006@googlemail.com> <1392155891.3990.15.camel@guybrush> <52FA9FD3.6000008@googlemail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090409000304030003080900" Subject: Re: [PHP-DEV] [RFC] [VOTE] __debugInfo() From: cryptocompress@googlemail.com (Crypto Compress) --------------090409000304030003080900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, so there maybe output not present in the object at all. Great source of confusion. Solutions to problems created by RFCs are inherent and should not be solved in followup RFCs. The __debugInfo RFC replaces one problem [1] by a subtile other one [2]. Why is it impossible to solve [1] and consequent [2] *within* this RFC? [1] way too big object dumps [2] no reliable way to create object dumps at all Thank you! cryptocompress --------------090409000304030003080900--