Re: [RFC] [VOTE] __debugInfo()
| From: | Crypto Compress | Date: | Wed, 12 Feb 2014 21:51:24 +0000 |
| Subject: | Re: [RFC] [VOTE] __debugInfo() | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-72529@lists.php.net to get a copy of this message | ||
Am 12.02.2014 21:58, schrieb Sara Golemon:
On Wed, Feb 12, 2014 at 12:40 PM, Crypto Compress <cryptocompress@googlemail.com> wrote:Sounds like an excuse to not think this RFC through to the end. *rush* *rush* I would not mind, but this reminds me on "$this in closures". Issues brought up by this RFC are currently non-existent. I stick to it: Solutions to problems created by RFCs are inherent and should not be solved in followup RFCs.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