Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72525
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.160.51 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <52FBDC4D.9020302@googlemail.com>
References: <CAESVnVq3PB+OFXGR+yJ1L2BuX_4+pHyjjvJ8rZXnxexXozyT4A@mail.gmail.com>
	<CAGfRu7Ot_sNhvQY1b18Wb-7UB3uihXsSXPVb=cHhEhA0s4ijVQ@mail.gmail.com>
	<52F00437.7010903@googlemail.com>
	<alpine.DEB.2.10.1402111838010.5374@whisky.home.derickrethans.nl>
	<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>
	<CAESVnVrB2OaAuLW5bA7B8S1rJSM371U+x1kEtNbdcaPw_3f85w@mail.gmail.com>
	<52FBDC4D.9020302@googlemail.com>
Date: Wed, 12 Feb 2014 12:58:45 -0800
Message-ID: <CAESVnVrtCzXhqDQU4PCunfXONoFM=z8+auukcU6t5PeLNFdBQQ@mail.gmail.com>
To: Crypto Compress <cryptocompress@googlemail.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [RFC] [VOTE] __debugInfo()
From: pollita@php.net (Sara Golemon)

On Wed, Feb 12, 2014 at 12:40 PM, Crypto Compress
<cryptocompress@googlemail.com> wrote:
> Solutions to problems created by RFCs are inherent and should not be solved
> in followup RFCs.
>
True, but I disagree that this RFC creates a problem in and of itself.
 The problem you describe comes from abuse of the feature and creating
__debugInfo() methods which hide relevant information.  Perhaps a
matter of semantics, but I think it's an important distinction.

> Why is it impossible to solve [1] and consequent [2] *within* this RFC?
>
It's not, however the vote has opened and substantially changing the
proposal after voting has started should not be done (as it
invalidates the votes already cast).  If the change is needed, then
voters should vote "No".  That will put this RFC back to the
discussion phase, we can add that feature, and reopen voting.

Personally, I think the issues you brought up deserve their own
independent discussion as there are a number of ways to accomodate the
issue you're envisioning.

If you feel strongly in that way, then I encourage you to vote No.  If
others on this list agree, then I encourage them to follow suit.

On the other hand, if those voting, as a majority, feel that this is
good enough as-is.  Then the vote passes and the feature goes in, and
we can propose another RFC to refine it.

-Sara