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())
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())
Can you change debugInfo to debuginfo in source code ... so it's
consistent with callstatic / tostring etc ...
Cheers
Joe
Hi Joe,
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())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
2014-02-04 Sara Golemon pollita@php.net:
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.
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
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
Meant output of var_dump is unexpected.
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
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?
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
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().
Ah, sorry, missed your clarification. Yes, we're on the same page.
-Sara
Hello Sara,
some more questions:
-
Can this hook be bypassed or disabled (global/temporary)?
e.g. real_var_dump(), ini setting, some other flag? -
What will be affected by this hook beside "var_dump"?
e.g. xdebug output, var_export, ... -
How would this behave (segfault?):
public function __debugInfo() { var_dump($this); return []; }
Thank You!
cryptocompress
On Tue, Feb 4, 2014 at 7:47 PM, Crypto Compress <
cryptocompress@googlemail.com> wrote:
Hello Sara,
some more questions:
Can this hook be bypassed or disabled (global/temporary)?
e.g. real_var_dump(), ini setting, some other flag?What will be affected by this hook beside "var_dump"?
e.g. xdebug output, var_export, ...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
Hi all,
On Tue, Feb 4, 2014 at 10:16 PM, Tjerk Meesters tjerk.meesters@gmail.comwrote:
some more questions:
Can this hook be bypassed or disabled (global/temporary)?
e.g. real_var_dump(), ini setting, some other flag?What will be affected by this hook beside "var_dump"?
e.g. xdebug output, var_export, ...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; }
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
Hi!
> 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; }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
Hi all,
On Tue, Feb 4, 2014 at 10:16 PM, Tjerk Meesters tjerk.meesters@gmail.comwrote:
some more questions:
Can this hook be bypassed or disabled (global/temporary)?
e.g. real_var_dump(), ini setting, some other flag?What will be affected by this hook beside "var_dump"?
e.g. xdebug output, var_export, ...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; }
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
On Tue, Feb 4, 2014 at 3:47 AM, Crypto Compress
cryptocompress@googlemail.com wrote:
- 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).
- 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
- 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
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
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]
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!
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
Sara Golemon wrote (on 05/02/2014):
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.
Yeah, I was just pulling that up in lxr. In its defence, the extra 1 is
an is_debug parameter which triggers creation of a temporary HashTable
instead of a permanently initialised one, and adds an '@attributes'
member, so somebody did make some effort...
I'm still just beginning to get my head round the engine code, so don't
hold your breath, but it's definitely something I'd like to help improve...
Rowan Collins
[IMSoP]
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
On Wed, Feb 5, 2014 at 12:01 PM, Crypto Compress
cryptocompress@googlemail.com 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
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%?).
a last request: Please add a big red sign to documentation to not hide
important information with this method. I will not argue on this any
further.
Thank You!
cryptocompress
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
Hi Sara,
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
Own goal par excellence if you want to hide something else no need for
this hook.
You can imagine the mess but want no proper solution. Why?
cryptocompress
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 11 February 2014 18:29, Crypto Compress cryptocompress@googlemail.comwrote:
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?
Solution:
1: Search for "__debugInfo" in project
2: Comment out function
3: Squash bug
4: Revert library code
If you're bug hunting with var_dump(), you are not adverse to temporarily
hacking at source code to add debug statements at weird places. You're
probably also hacking out all your normal exception handling and output
formatting to get the dump to display on screen. So why wouldn't you be
prepared to hack this too?
--G
If you're bug hunting with
var_dump(), you are not adverse to
temporarily hacking at source code to add debug statements at weird
places.
As this method has "debug" in it, it's purpose is uncontroversial
bughinting. Isn't it?
How many objects are in a avarage orm to temporarily be hacked? In
comparison to var_dump($wholeObjectGraph) justifiable?
You're probably also hacking out all your normal exception handling
and output formatting to get the dump to display on screen. So why
wouldn't you be prepared to hack this too?
Why display on screen? $foo->log(print_r($bar, true)); is impossible too.
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.)
--
Rowan Collins
[IMSoP]
Am 11.02.2014 21:06, schrieb Rowan Collins:
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().
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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.
On 3 February 2014 21:11, Crypto Compress cryptocompress@googlemail.comwrote:
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
nocorrectly-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
newweird/broken/counter-intuitive code like you write is certainly
valid. But
it's not a B/C issue.
--G
Meant output of var_dump is unexpected.
The fact that with this function developers can write
newweird/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.
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
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" }
__ method names are reserved for internals. There is no BC break.
cheers,
Derick
__ method names are reserved for internals. There is no BC break.
Yes, there is however an expectation break but thats not the Point. May
even be useful.
Imagine a mock library:
Usecase #1: end-user
Sees only immediate useful data. No cluttered object graph. Very useful!
Usecase #2: new maintainer
Hunting bug in mock object. No way to var_dump object internals at all.
Wait what?
__ method names are reserved for internals. There is no BC break.
Yes, there is however an expectation break but thats not the Point. May
even be useful.Imagine a mock library:
Usecase #1: end-user
Sees only immediate useful data. No cluttered object graph. Very useful!Usecase #2: new maintainer
Hunting bug in mock object. No way to var_dump object internals at all.
Wait what?
This is still no BC break in PHP but probably bad usage. You can still
see "the truth" via reflection and by using a proper debugger (like
xdebug, I assume)
johannes
You can still see "the truth" via reflection and by using a proper debugger (like xdebug, I assume)
Reflection is mentioned in RFC. Sadly it does not solve the problem.
Replaced output is not bypassable without external tools
(xdebug/phpdbg). If i'am wrong correct me.
You can still see "the truth" via reflection and by using a proper debugger (like xdebug, I assume)
Reflection is mentioned in RFC. Sadly it does not solve the problem.
Replaced output is not bypassable without external tools
(xdebug/phpdbg). If i'am wrong correct me.
ReflectionObject provides access to an object and its properties. This
is not going to change in case this is accepted. It will be extended toe
able to also provide this debug info, this doesn't affect
ReflectionObject::getProperty() etc., though.
johannes
Am 11.02.2014 22:12, schrieb Johannes Schlüter:
You can still see "the truth" via reflection and by using a proper debugger (like xdebug, I assume)
Reflection is mentioned in RFC. Sadly it does not solve the problem.
Replaced output is not bypassable without external tools
(xdebug/phpdbg). If i'am wrong correct me.
ReflectionObject provides access to an object and its properties. This
is not going to change in case this is accepted. It will be extended toe
able to also provide this debug info, this doesn't affect
ReflectionObject::getProperty() etc., though.johannes
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.
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.
Yes that is the purpose of this RFC and that voters have to decide
about: evaluate risk of abuse vs. making unreadable results usable.
johannes
Am 11.02.2014 22:58, schrieb Johannes Schlüter:
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.
Yes that is the purpose of this RFC and that voters have to decide
about: evaluate risk of abuse vs. making unreadable results usable.johannes
No, it's not about risk of abuse. There can be only abuse!
This hook is only intended to hide debug information. If you don't want
to hide info, you don't need this hook.
Debug info is important! Do not hide it without a option to bypass!
Why not make it an enhancement to poor man's debugger and add a
proper/easy/fast bypass option in this RFC?
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
On Tue, Feb 11, 2014 at 2:10 PM, Crypto Compress
cryptocompress@googlemail.com wrote:
No, it's not about risk of abuse. There can be only abuse!
This hook is only intended to hide debug information. If you don't want to
hide info, you don't need this hook.
Debug info is important! Do not hide it without a option to bypass!
That statement is incorrect.
This hook is not only intended to hide debug information. It can just
as easily be used to expose more debug information.
For example:
class MyMySQL {
protected $conn;
public function __debugInfo() {
return [
'conn' => $this->conn,
'encoding' => mysql_client_encoding($this->conn),
'error' => mysql_error($this->conn),
'info' => mysql_info($this->conn),
// etc...
}
}
Here, our mysql wrapper class exposes a great deal more information
for use when debugging what went wrong. Not less. Therefore I refute
your statement.
-Sara
Hi,
so there maybe output not present in the object at all. Great source of
confusion.
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
On Wed, Feb 12, 2014 at 12:40 PM, Crypto Compress
cryptocompress@googlemail.com wrote:
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
Am 12.02.2014 21:58, schrieb Sara Golemon:
On Wed, Feb 12, 2014 at 12:40 PM, Crypto Compress
cryptocompress@googlemail.com wrote: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
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.
Crypto Compress wrote (on 12/02/2014):
so there maybe output not present in the object at all. Great source
of confusion.
What if the object makes use of __get and __set, but in a systematic
way? Is it more "true" to represent it as having those virtual
properties, or not having them?
It clearly depends on the use case, but it is certainly not only about
hiding information, it can be about exposing information useful to
the user of the object.
It still feels to me that someone debugging the implementation of the
object, rather than its interaction with the system, would have plenty
of opportunity to by-pass / remove the hook anyway.
Regards,
Rowan Collins
[IMSoP]
It still feels to me that someone debugging the implementation of the
object, rather than its interaction with the system, would have plenty
of opportunity to by-pass / remove the hook anyway.
What about a phar? It's not easy nor fast to change X times
__debugInfo() methods.
Crypto Compress wrote (on 12/02/2014):
It still feels to me that someone debugging the implementation of the
object, rather than its interaction with the system, would have
plenty of opportunity to by-pass / remove the hook anyway.What about a phar?
My point was that if you're debugging the implementation, you're going
to be looking at the source tree, not the distribution.
If you're looking at a distributed version, your main interest is in how
to use the objects, which the maintainer can give you hints for via
__debugInfo()
It's not easy nor fast to change X times __debugInfo() methods.
True. I can't really picture somebody adding carefully crafted methods
to every class they write, though; more likely, it will be defined in
some ancestor class, or maybe even a trait, so you'd change it there,
and the whole object graph would go back to "normal".
I guess generated code might include it, but then you'd probably have
the option of re-generating it without (again, if you were interested in
the implementation of the objects, rather than just the use of them).
Regards,
Rowan Collins
[IMSoP]
Am 12.02.2014 23:08, schrieb Rowan Collins:
Crypto Compress wrote (on 12/02/2014):
It still feels to me that someone debugging the implementation of
the object, rather than its interaction with the system, would have
plenty of opportunity to by-pass / remove the hook anyway.What about a phar?
My point was that if you're debugging the implementation, you're
going to be looking at the source tree, not the distribution.If you're looking at a distributed version, your main interest is in
how to use the objects, which the maintainer can give you hints for
via __debugInfo()It's not easy nor fast to change X times __debugInfo() methods.
True. I can't really picture somebody adding carefully crafted methods
to every class they write, though; more likely, it will be defined in
some ancestor class, or maybe even a trait, so you'd change it there,
and the whole object graph would go back to "normal".I guess generated code might include it, but then you'd probably have
the option of re-generating it without (again, if you were interested
in the implementation of the objects, rather than just the use of
them).Regards,
some cool ideas worth spreading :)
Crypto Compress wrote (on 12/02/2014):
so there maybe output not present in the object at all. Great source of
confusion.What if the object makes use of __get and __set, but in a systematic way? Is
it more "true" to represent it as having those virtual properties, or not
having them?
Extremely excellent point. I can think of a few classes I wrote at
Yahoo which fall into that bucket.
-Sara
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:
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!
Crypto Compress wrote (on 11/02/2014):
You can still see "the truth" via reflection and by using a proper
debugger (like xdebug, I assume)Reflection is mentioned in RFC. Sadly it does not solve the problem.
Replaced output is not bypassable without external tools
(xdebug/phpdbg). If i'am wrong correct me.
The presence of Reflection methods for telling the truth means that a
tool can be built entirely in userland (as long as Reflection ext is
enabled), which is a lot less "external" than something like xdebug/phpdbg.
Regards,
Rowan Collins
[IMSoP]
Hi Sara,
https://wiki.php.net/rfc/debug-info
I can't resist telling you about
patchwork/dumperhttps://github.com/nicolas-grekas/Patchwork-Dumperbecause
it has all you seem to look for.
Except internal info that are hidden from user land, it has a higher
accuracy than var_dump(), because it can dump soft and hard references
inside complex data structures. It also offers tailor made output with the
ability to enrich objects/resources with custom
"casters"https://github.com/nicolas-grekas/Patchwork-Dumper/tree/master/class/Patchwork/Dumper/Caster
.
Maybe this can fuel some ideas?
For example, I would suggest that any error thrown from a call to
__debugInfo() should be ignored by var_dump()/print_r().
Cheers,
Nicolas