From: Stephen White <steve@...>
Date: 2000-11-07T23:51:49+09:00
Subject: [ruby-talk:6125] Re: What would a Ruby browser look like?

On Tue, 7 Nov 2000, Conrad Schneiker/Austin/Contr/IBM wrote:

> I think it might also be useful to ask, why do you want a browser anyway? 
> What are the specific types of information it provides, what purposes does
> it serve in various cases, and so on? Are there some other methods
> (hyperlinks, colored code sections, or whatever) that could do this more
> directly? Maybe not, but you might still discover some better way to do
> classical browsers in the process of re-examining such things.

This is a good point. The other class browsers I've used have been quite
nice, but the information was separate from the code itself, so I had to
apply the context myself. I would have preferred for this information to
be visible in the code, in its natural context.

For example, I would like to be able to click on a function declaration and
see a list of all functions that call it. I would like to be able to select
to modify the function name and all the calls will be updated so changing
names is just a click away, not a boring grep, update, repeat, grep...

I would like to back out to a higher level view of the code. Sometimes
I'm not interested in the details - I just want to be able to see which
functions are associated with each other. Have a look at:

  http://deaf.org/srced/

for a couple of screenshots of a prototype I did in Tcl/Tk to explore
this concept. The graphing program is displaying its own code in two
views - a "call" view to show calls being made, and a "globals" view
to show accesses to global variables.

It's surprisingly useful being able to click on a node to get the editor
window. It turns my normal scroll up/down coding sessions into "drill
down, edit, pop back" with the bonus of keeping the big picture a little
more visible. I'd had enough of Tcl by this point, but the next step was
going to be spending a couple of nights being able to group functions
into a block, then backing out to see the overall program structure.

It would be cool to run a Ruby program and see the diagram updated in
(slow) real time, with lines flashing to show calls being made and data
being accessed. Red for writes, yellow for reads? Ruby red for the node
currently running (lighter red for threads?) and profiling information
being updated on all the nodes as the program executes. That's dreaming
a bit, but I like it. :)

Hugh made a good point when he said we have to determine what this is
going to do. The wish list I've got here is more of a refactoring tool
than a code browser. I would like to have these refactoring tasks built
into my editor, so I can have unit tests run automatically when I move
the cursor out of a function I've edited, be able to rename functions
and variables and have all references updated, move a function from
one class to another and so on... all of which are very simple tasks
performed mechanically. It could almost be done with a sed script, but
just needs a little bit of parsing knowledge.

We'd need a couple of things to do this...

  A parser. Would be nice if Ruby itself had an API to its engine
  so the parsing is guaranteed to be correct (bugs and all!).

  A database. Results from parsing project, accepts queries and
  information updates.

  Editor interface. Nice easy stuff for any editor to hook into to
  provide interactive code aware goodies.

  Various views, eg, graphical, documentation, Quake maps...

I'm a procedural dinosaur trying to avoid a Darwin Award, so my design
sketches lack that true OO vision, but it all looks very doable. What
do you guys think?

How well does Smalltalk's refactoring browser work in practice? Would
it be better to provide GOF type refactorings, or a lower level system
of reminder tags and highlights?

Would it be feasible to look into handling multiple languages, so as
to be able to cross over to C code when following Ruby functions?

-- 
  steve@deaf.org