class Foo does Debuggable ...
Yuval Kogman
when we want to invoke the debugger), or too much is visible (this
is when we give up on tracing the problem through the debugger, and
resort to print Data::Dumper::Dumper($thing) every few lines of
code).
Given the complexity of layering in todays programs, lets take a web
app for example (search for __skip__ if you want to skip):
request enters glue code to environment
MVC framework builds request object
controller actions dispatch, object moves around
model queried, changed
view dispatched
request luggage data munged, or model requeried
template module invoked
This involves, framework code, we typically don't care about, which
in turn is just glue around other frameworks and libraries:
- our POOP library
- on top of DBI, which we also don't care about
- lots of hackery to create an OOP data view
- lots of lazy accessors, doing big work under the hood
- our template library
- uses a bajillion plugins, probably
- uses has a complex pipeline, to process a template, with
caching (memory, files), translation, parsing, inlining, and
outputting, like any modern system
- our environment glue library
- mod_perl / CGI
- HTTP::Headers, etc
We are also introduced with a new control flow paradgim, probably
one of:
- a run loop
- callbacks
- continuations
- beh
__skip__
programs that are written by the user are hard to debug. Lots of the
code actually being run is far from the code that we wrote.
In this day and age of complex application writing debuggers are
hard to get right. Lets briefly discuss their evolution:
1. machine code dissasembly + tracing
2. source debugger
...
That's where they stopped i think.
The big distinction between the two is that the latter is at the
user's level - it discusses the thing that the user wrote.
The next step is to allow a debugger to hide library code when it's
beyond what the user cares about, since although it's at the same
level, it's still not what the user wrote.
I think the way to do it is to make a debuggable role, which knows
to provide a million and one hooks to the thing that `does` it.
Aside from that, I don't really know how to think farther.
The two implications I'd like to see:
1. Code ownership marked at runtime:
Framework providing several levels of how to skim through control
flow. Probably usually boolean (calls within a namespace omitted).
Also defines a policy about instance data it filled in, and so
forth.
This allows the user to skim through only their code, or only some
of the libraries mechanisms if that helps.
2. Data summarization
Complex structures should know how to display themselves well to a
debugger.
Of course, for this stuff to work, it has to be part of the grand
unified tracing and introspection capabilities Perl 6 will offer a
debugger writer. I'd like to see this in use by N debuggers,
possibly with a role like mechanism (in a graphical debugger some
objects may know how to draw themselves).
Also, lets remember not to hinder full transparency. Furthermore,
full transparency should, again, not be all or nothing.
I believe developers will be tempted to write implementations of the
Debuggable role, since they will probably use these tools to debug
their own code anyway ;-)
Adios!
--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM: neeyah!