Re: [RFC] [VOTE] __debugInfo()
| From: | Crypto Compress | Date: | Tue, 11 Feb 2014 20:23:29 +0000 |
| Subject: | Re: [RFC] [VOTE] __debugInfo() | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-72471@lists.php.net to get a copy of this message | ||
Am 11.02.2014 21:06, schrieb Rowan Collins:
On 11/02/2014 18:29, Crypto Compress wrote: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.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) )
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.