[RFC] [VOTE] __debugInfo()

> Hello Sara, > > some more questions: > > 1. Can this hook be bypassed or disabled (global/temporary)? > e.g. real_var_dump(), ini setting, some other flag? > > 2. What will be affected by this hook beside "var_dump"? > e.g. xdebug output, var_export, ... > > 3. How would this behave (segfault?): > public function __debugInfo() { var_dump($this); return []; } >

> > Thank You! > > cryptocompress > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >

> 1. Can this hook be bypassed or disabled (global/temporary)? > e.g. real_var_dump(), ini setting, some other flag? >

> 2. What will be affected by this hook beside "var_dump"? > e.g. xdebug output, var_export, ... >

> 3. How would this behave (segfault?): > public function __debugInfo() { var_dump($this); return []; } >

> Sorry! We talk at cross purposes: > - reflection is not changed > - (array)$this is possible > > This is currently not needed nor related to var_dump(). This RFC changes > var_dump/print_r output without a bypass option. Hacks are needed to get > current behavior back. Indeed it may be possible to replace > var_dump/print_r with something. This discussion is about this issue.

> 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

> 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.

> 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().