please determine whether inclusion in core should also include usefulness with the debugger
Closed this issue · 3 comments
Right now the debugger library in core provides the x facility to dump objects, which appears to also be used programmatically by third parties in order to provide runtime object inspection while debugging in more advanced UIs than the bare command line.
Right now for most standard objects the output looks like this:
DB<1> x $x
0 Point=HASH(0x800420ab8)
'x' => 5
'y' => 10
DB<2>
With Object::Pad as the prototype, things look like this:
DB<1> x $x
0 Point=ARRAY(0x800822168)
0 5
1 10
DB<2>
The second option "works" for an object as simple as this, but is hopefully obviously useless for anything of substance.
Any object dump facility might be helpful, but if decided to be the way, should be integrated in the perl core debugger library's x if this OO is to be part of the core, and it is decided this "feature" should remain usable.
If not, it should be documented clearly that the feature is broken for this type of object, and workarounds explained.
Both Data::Dumper and the debugger will definitely need to handle the objects in some way that is useful for debugging.
As for workarounds with Object::Pad: I'm using Object::Pad too much to live without debugger support, so I've hacked the Perl debugger by using O::P's meta protocol:
https://gist.github.com/HaraldJoerg/1108155847ab48a1c115a8054e878d5a
Changing data with the debugger, however, is a different piece of cake and not (yet) implemented. The Perl debugger offers no command to change data: it is done by entering valid Perl statements. However, there are no valid Perl statements to change slot data which don't have a :writer - unless one is on a breakpoint within the object's class.