# [RFC] [VOTE] __debugInfo() - Thread: https://externals.io/message/72112 - Original archive: https://news-web.php.net/php.internals/72112 - Started by Sara Golemon on 2014-02-03T20:06:19+00:00 - Messages: 55 - RFC: __debugInfo() magic method (Implemented (PHP 5.6)) — https://externals.io/rfc/debug-info.md - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/72112.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #72112 — Sara Golemon — 2014-02-03T20:06:19+00:00 URL: https://externals.io/message/72112#72112 Voting is now open with options which PHP version to release with and how to name it (since some seem to prefer the more compact __debug()) https://wiki.php.net/rfc/debug-info --- ## #72114 — Joe Watkins — 2014-02-03T20:16:50+00:00 URL: https://externals.io/message/72112#72114 · In reply to: #72112 > Voting is now open with options which PHP version to release with and > how to name it (since some seem to prefer the more compact __debug()) > > https://wiki.php.net/rfc/debug-info > Can you change debugInfo to debuginfo in source code ... so it's consistent with callstatic / tostring etc ... Cheers Joe --- ## #72115 — Yasuo Ohgaki — 2014-02-03T20:21:35+00:00 URL: https://externals.io/message/72112#72115 · In reply to: #72114 Hi Joe, > > > > […] > Can you change debugInfo to debuginfo in source code ... so it's > consistent with callstatic / tostring etc ... We should stick to naming rules for new features. Otherwise, we'll have more mess... Legacy names should be cleaned up some day, hopefully... Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #72117 — chobie — 2014-02-03T20:40:10+00:00 URL: https://externals.io/message/72112#72117 · In reply to: #72112 2014-02-04 Sara Golemon : > Voting is now open with options which PHP version to release with and > how to name it (since some seem to prefer the more compact __debug()) > > https://wiki.php.net/rfc/debug-info > > -- > > > great! I've sometimes thought if I could hide unwanted property in user defined class. btw, how can I make an array which has visibility prefixed key (like \0*\0b) easily? i don't mind current one. but I guess almost php users doesn't know that. --- ## #72119 — Crypto Compress — 2014-02-03T21:03:51+00:00 URL: https://externals.io/message/72112#72119 · In reply to: #72117 Hi! This is a somewhat unexpected BC break in a point release. Why no 6.0 option? class Dog { public function __debugInfo() { return ['Cat']; } } var_dump(new Dog); // Array { "Cat" } Name is a bit ambiguous. This method does not debug anything as in xdebug or phpdbg. It exposes internal "__state". cryptocompress --- ## #72121 — Yasuo Ohgaki — 2014-02-03T21:08:02+00:00 URL: https://externals.io/message/72112#72121 · In reply to: #72119 Hi Crypto, On Tue, Feb 4, 2014 at 6:03 AM, Crypto Compress < cryptocompress@googlemail.com> wrote: > This is a somewhat unexpected BC break in a point release. Why no 6.0 > option? > class Dog { public function __debugInfo() { return ['Cat']; } } > var_dump(new Dog); // Array { "Cat" } > > Name is a bit ambiguous. This method does not debug anything as in xdebug > or phpdbg. It exposes internal "__state". > __someMethod() is reserved name for internal use and it is explicitly documented. If it breaks, it's users fault. We cannot cover all of user faults... Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #72123 — Crypto Compress — 2014-02-03T21:11:02+00:00 URL: https://externals.io/message/72112#72123 · In reply to: #72121 Meant output of var_dump is unexpected. --- ## #72128 — Yasuo Ohgaki — 2014-02-03T21:34:11+00:00 URL: https://externals.io/message/72112#72128 · In reply to: #72123 Hi Crypto, On Tue, Feb 4, 2014 at 6:11 AM, Crypto Compress < cryptocompress@googlemail.com> wrote: > Meant output of var_dump is unexpected. I don't think output of `var_dump()` would change. Is it correct, Sara? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #72129 — George Bond — 2014-02-03T21:35:03+00:00 URL: https://externals.io/message/72112#72129 · In reply to: #72123 On 3 February 2014 21:11, Crypto Compress wrote: > Meant output of var_dump is unexpected. But that's not a B/C *break*, because users are explicitly instructed not to write functions beginning with double underscores unless they want magic functionality, and since this is *new* magic functionality *no*correctly-constructed code will contain a function named "__debugInfo()". Any old code which does contain such a function is already explicitly standards-defying, and so does not deserve any B/C maintenance. That's the whole point in reserving the whole namespace of double-underscore-prefixed functions for future magic behaviour. The fact that with this function developers can write *new*weird/broken/counter-intuitive code like you write is certainly valid. But it's not a B/C issue. --G --- ## #72131 — Stas Malyshev — 2014-02-03T21:46:43+00:00 URL: https://externals.io/message/72112#72131 · In reply to: #72119 Hi! > This is a somewhat unexpected BC break in a point release. Why no 6.0 > option? Names prefixed with __ are reserved for system use. You should never ever name anything in user code starting with __. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #72133 — Crypto Compress — 2014-02-03T21:50:42+00:00 URL: https://externals.io/message/72112#72133 · In reply to: #72129 > > […] > The fact that with this function developers can write > *new*weird/broken/counter-intuitive code like you write is certainly > valid. But it's not a B/C issue. > Valid point. This can't be BC issue as such code is nonexistent. It will confuse later on. --- ## #72135 — Yasuo Ohgaki — 2014-02-03T21:55:13+00:00 URL: https://externals.io/message/72112#72135 · In reply to: #72128 Hi Crypto, > On Tue, Feb 4, 2014 at 6:11 AM, Crypto Compress < > cryptocompress@googlemail.com> wrote: > > > […] > > > I don't think output of `var_dump()` would change. > Is it correct, Sara? > The sentence may be confusing. __debugInfo() changes `var_dump()` output. However, existing code will not be affected, since user should have __debugInfo(). Therefore, it cannot be a BC issue. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #72140 — Sara Golemon — 2014-02-03T22:13:13+00:00 URL: https://externals.io/message/72112#72140 · In reply to: #72128 > I don't think output of `var_dump()` would change. > Is it correct, Sara? > The output of `var_dump()` *would* change. That's the point of the debug info hook. But as you say, it's still not relevant as __ is a reserved namespace. -Sara P.S. 5.6 isn't a point release, it's a minor release. Point releases are updates to the third number, and I agree introducing it in a point release would be a bad idea. --- ## #72142 — Sara Golemon — 2014-02-03T22:14:31+00:00 URL: https://externals.io/message/72112#72142 · In reply to: #72135 > > > […] > > The sentence may be confusing. __debugInfo() changes `var_dump()` output. > However, existing code will not be affected, since user should have > __debugInfo(). > Ah, sorry, missed your clarification. Yes, we're on the same page. -Sara --- ## #72193 — Crypto Compress — 2014-02-04T11:47:55+00:00 URL: https://externals.io/message/72112#72193 · In reply to: #72142 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 --- ## #72196 — Tjerk Meesters — 2014-02-04T13:16:22+00:00 URL: https://externals.io/message/72112#72196 · In reply to: #72193 On Tue, Feb 4, 2014 at 7:47 PM, Crypto Compress < cryptocompress@googlemail.com> wrote: > 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 []; } > Yeah, there doesn't seem to be any recursion protection, just like: public function __toString() { return (string)$this; } > > Thank You! > > cryptocompress > > > -- > > > > -- -- Tjerk --- ## #72226 — Yasuo Ohgaki — 2014-02-05T00:24:15+00:00 URL: https://externals.io/message/72112#72226 · In reply to: #72196 Hi all, On Tue, Feb 4, 2014 at 10:16 PM, Tjerk Meesters wrote: > > […] > > Yeah, there doesn't seem to be any recursion protection, just like: > > public function __toString() { return (string)$this; } It is the same as function f() { f(); } User may do that, but it's a documentation problem. It would be not obvious as function call recursion. and must be documented, probably. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #72272 — Crypto Compress — 2014-02-05T13:46:50+00:00 URL: https://externals.io/message/72112#72272 · In reply to: #72226 Hi! > > […] > > Yeah, there doesn't seem to be any recursion protection, just like: > > public function __toString() { return (string)$this; } > > > It is the same as > > function f() { > f(); > } > > User may do that, but it's a documentation problem. > It would be not obvious as function call recursion. > and must be documented, probably. > var_dump has *no* recursion check unlike print_r --- ## #72279 — Julien Pauli — 2014-02-05T17:05:24+00:00 URL: https://externals.io/message/72112#72279 · In reply to: #72226 > Hi all, > > On Tue, Feb 4, 2014 at 10:16 PM, Tjerk Meesters wrote: > > > […] > > > It is the same as > > function f() { > f(); > } > > User may do that, but it's a documentation problem. > It would be not obvious as function call recursion. > and must be documented, probably. Yup, AFAIK, the only recursion calls we check against are in __get() and __set() handlers, that's all. I admit the __tostring() casting $this to string is tricky ;-) I suggest we dont implement recursion checks for debug_info neither. Julien.P --- ## #72285 — Sara Golemon — 2014-02-05T18:38:52+00:00 URL: https://externals.io/message/72112#72285 · In reply to: #72193 On Tue, Feb 4, 2014 at 3:47 AM, Crypto Compress wrote: > 1. Can this hook be bypassed or disabled (global/temporary)? > e.g. real_var_dump(), ini setting, some other flag? > No. The existing get_debug_info behavior is always active and this RFC just lifts it up to the userspace level. Is there a specific use case for which you'd like that? I suppose you could always do: var_dump((array)$obj); and get the "real" prop info. In practice, an object would use this hook to provide better info, keeping implementation details out of the way (such as current uses in dom, sxe, mysqli, intl, and spl). > 2. What will be affected by this hook beside "var_dump"? > e.g. xdebug output, var_export, ... > `var_dump()` and `print_r()` are the only current uses of get_debug_info > 3. How would this behave (segfault?): > public function __debugInfo() { var_dump($this); return []; } > Badly (most likely timeout or memory limit E_ERROR). Don't do that. -Sara --- ## #72286 — Rowan Collins — 2014-02-05T19:30:26+00:00 URL: https://externals.io/message/72112#72286 · In reply to: #72285 Sara Golemon wrote (on 05/02/2014): > (such as current uses in dom, > sxe, mysqli, intl, and spl) If "sxe" in there means SimpleXML, I wish it would do a better job of it! There are countless questions on StackOverflow, and comments in the PHP manual, confused by its mention of "array", "@attributes", etc, and the fact that it omits CDATA nodes, any text node with a non-text sibling, anything in a namespace, etc, etc e.g. http://3v4l.org/h6KeF In fact, now that I know this hook exists, and doesn't affect the action of array casts, I'm tempted to attempt a patch that would improve it, based on the simplexml_tree function I've written at https://github.com/IMSoP/simplexml_debug I guess even if I don't get good enough at C hacking, I could write a version using this new user-land callback :) It's a shame it can't (AIUI) return a completely pre-formatted string, so that complex objects wouldn't have to pretend to contain arrays in order to represent nested properties. -- Rowan Collins [IMSoP] --- ## #72289 — Crypto Compress — 2014-02-05T20:01:04+00:00 URL: https://externals.io/message/72112#72289 · In reply to: #72285 Am 05.02.2014 19:38, schrieb Sara Golemon: > The existing get_debug_info behavior is always active and this > RFC just lifts it up to the userspace level. Is there a specific use > case for which you'd like that? I suppose you could always do: > var_dump((array)$obj); and get the "real" prop info. What info someone want to see is highly *context/situation and person dependent*. As i wrote i use __tostring extensively for this specific purpose. For 99% of the time i am happy with compact/trimmed output of importance and there is this other case (mostly urgent), to see the full state of the whole object graph (yeah, recursive too). The issue occurred is somewhat analogous with "escaping on input" or "private/protected discussion": - sanitize: information is missing on output - escape html: read garbage on command line/logs - private: can't change bad design easily (- it's not about security) Changing class definitions/methods of whole object graph is obviously not an option. Casting to array is of no help as only for current object and only for public props. Rephrased: Someone (my younger self :D) can decide what i do *not* need to see in my logs/debug-output and there would be no easy/fast way to bypass. cryptocompress --- ## #72290 — Sara Golemon — 2014-02-05T20:01:49+00:00 URL: https://externals.io/message/72112#72290 · In reply to: #72286 > Sara Golemon wrote (on 05/02/2014): > > […] > > If "sxe" in there means SimpleXML, I wish it would do a better job of it! > Yes, sxe is short for SimpleXML. :) > In fact, now that I know this hook exists, and doesn't affect the action of > array casts, I'm tempted to attempt a patch that would improve it, based on > the simplexml_tree function I've written at > https://github.com/IMSoP/simplexml_debug > Wanna lol? Here's sxe's current implementation of get_debug_info (in ext/simplexml/simplexml.c) static HashTable * sxe_get_debug_info(zval *object, int *is_temp TSRMLS_DC) { *is_temp = 1; return sxe_get_prop_hash(object, 1 TSRMLS_CC); } If you can even call that an implementation. :p If you're up to improving it, that's the spot to do it. -Sara --- ## #72291 — Sara Golemon — 2014-02-05T20:04:45+00:00 URL: https://externals.io/message/72112#72291 · In reply to: #72289 On Wed, Feb 5, 2014 at 12:01 PM, Crypto Compress wrote: > Rephrased: Someone (my younger self :D) can decide what i do *not* need to > see in my logs/debug-output and there would be no easy/fast way to bypass. > Apart from the aforementioned array cast which is both easy and fast. Personally, I think the potential for improving debug output far outweighs the potential for abusing it to hide important info. -Sara --- ## #72292 — Crypto Compress — 2014-02-05T20:11:48+00:00 URL: https://externals.io/message/72112#72292 · In reply to: #72291 > Apart from the aforementioned array cast which is both easy and fast. > It's not easy nor fast to change output of a whole object graph. > Changing class definitions/methods of whole object graph is obviously not an option. > Casting to array is of no help as only for current object and only for public props. > Personally, I think the potential for improving debug output far > outweighs the potential for abusing it to hide important info. > > -Sara Yes, so why not add extra method for this? "pretty_dump()" This "abuse" is way common then you think (99%?). --- Next page: https://externals.io/message/72112.md?page=2