[ruby-talk:6845] Re: Refactoring Browser.

On Wed, 6 Dec 2000, Conrad Schneiker wrote:

> John Carter writes:
> 
> # Is there someone somewhere developing a Ruby refactoring browser?
> 
> Then there was the issue of whether Tk was a tolerable GUI choice for 
> something that would hopefully grow into a full-fledged industrial-strengh 
> IDE.

Hmm. The joys of wxWindows aside, I have a couple of hard earned rules
of programming life...
 * Never write a sort routine, you'll never get it as smart as the gnu
   qsort.
 * Never check for an error condition you don't know how to handle.
 * Never write an editor. (A lot of the glueyist of gui's would magically
   vanish if people held to that one...)

I would tack it onto Emacs. Let Emacs be the IDE, its _very_ good at that.  
And let the RRB (Ruby Refactoring Browser) handle the parsing, treewalking
scanning, structure display, transforming, rewriting etc. etc. There is an
interesting thread going that mentioned a perl/elisp tie up.  

Of course, displaying the inheritance tree etc. etc. you can do in
wxWindows, and when you go "click-edit that" it merely tells emacs to open
that file at that position!

> By the way, what specific capabilities should a Ruby *refractoring* 
> browser (minimally, maximally) have?

I will admit that I know Perl/C++/Actor/Scheme/... far better than Ruby.
Developing an RRB appealed to me because one always makes a bit of a muck
of the first big app one does in a new language. I always have this strong
urge to go back and redo it once I have done it. Thus giving me an
immediate, intense and cross-meta levels use for the RRB... :-)

Capabilities....
1. Find/list all invocations of method X of class Y.
2. Rename all invocations.
3. Find/list all instance variables.
4. Find/Highlight all references to certain local variables.
5. Extract method - Highlight a region, invoke extract method, RRB
displays the "hair" thats stopping it. ("Hair" = data and control
dependencies that prevent an "extract method".) Or if nothing prevents it,
extracts and names method, and drops a invocation where method was.

I even think one could in a limited but useful sense automate the
selection of regions to extract. eg.
  * Highlight nested blocks of the dependency structure.
  * Search for largest regions of code that are duplicate after
    squashing whitespace replacing all identifiers and
    all numbers by TOKEN. eg.
    a = b + 1 becomes TOKEN=TOKEN+TOKEN
    fred=tom+dick becomes TOKEN=TOKEN+TOKEN 
    Thus we have a candidate, a bad candidate admittedly, 
    for extracting method harry(a,b,c) {a=b+c}

Most refactorings seem to have at there heart "Extract method". If one
could just do that well, coupled with an Ruby sensitive (globally
across all files in app) "query replace" you are more than halfway
there.

YAGNI! I'm willing to bet if you look at the actual usage patterns of the
Smalltalk RB, you would find that you get 80% there by having :-
a) A Language sensitive global search.
b) A Language sensitive global query search & replace.
c) An extract method tool.

From that good sound basis one can build on.

(OK, I have _never_ used the Smalltalk RB so I may very well be
talking total rubbish, but I have refactored by hand (before I had a
nice politically correct name to apply to the activity) very many C++
/ Perl / ... programs. You will be amazed at how much refactoring I
can do with Emacs Macros and a clever wee perl script that allows me
to do very rapid perl regex searches on all 2000+ C++ files in the system
I work on.) (Hint: Use Emacs "compile" command and 
"grep -nE 'regex' *.c* *.h*" then hits show up as "compile errors".
Hit "enter" on the "error" and Emacs takes you there...)

Warning: There is quite a lot hiding under the term "language
sensitive search". 

John Carter

Work Email : [e-mail] Private email : [e-mail] 
Yell Phone : [phone]      Phone         : [phone]

Carter's Compass...

   I know I'm on the right track when by deleting code I'm adding
   functionality.