Re: [RFC] [VOTE] __debugInfo() [summary]

Good evening, ladies and gentlemen! 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 p.s.: As most of you don't have time to read all the posts, a chronological summary: ---------- 1/3 ---------- Am 05.02.2014 21:54, schrieb Sara Golemon:

On Wed, Feb 5, 2014 at 12:11 PM, Crypto Compress <cryptocompress@googlemail.com> wrote:

It's not easy nor fast to change output of a whole object graph.

Oh, I see what you were getting at now. Yeah, that would be onerous if you found yourself in that position. Might be a good idea to do a followup RFC to introduce an INI setting. I'm not keen on adding a new method, that kind of misses the point of the original hook. -Sara

---------- 2/3 ---------- Am 11.02.2014 21:23, schrieb Crypto Compress:

Am 11.02.2014 21:06, schrieb Rowan Collins:

On 11/02/2014 18:29, Crypto Compress wrote:

Imagine a proxy object (orm). Usecase #1: end-user Sees only proxied object. No cluttered object graph. Very useful! Usecase #2: new maintainer Hunting bug in proxy object. No way to dump internals at all. Wait what?

On the other hand, usecase #3: hunting bug in incredibly complex object and "can't see the wood for the trees" because object graph fills pages of output. Temporarily (re-)implement __debugInfo() to output a few relevant properties, and all becomes much clearer. I could have used this earlier today, in fact; I ended up with something like dump( array($this->foo, $this->bar, $this->baz) )

Yes! I'm convinced this hook is a very useful extension for poor man's debugger. Would like to see status quo enhanced, not replaced.

There might be merit in a way of viewing the "real" contents of an object, I guess, although that doesn't have any meaning for objects exposed by extensions anyway, as they can overload in ways user-land can only dream of. (Hence SimpleXML being so confusing if you try to debug it as though it were a "real" object.)

Yes again! Got headache thinking of userland devs get this power without a way to bypass it.

---------- 3/3 ---------- Am 11.02.2014 21:54, schrieb Stas Malyshev:

Hi!

Usecase #2: new maintainer Hunting bug in proxy object. No way to dump internals at all. Wait what?

That's exactly what would routinely happen with this proposal. People would use __debugInfo to pretty-print their object structure, and then discover they actually have no way to know what's *really* there when their pretty-printer does not work or does not supply needed information. So they would eventually ask for real_var_dump().

Thank you again!