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 : john / netsys.co.za Private email : cyent / mweb.co.za Yell Phone : 083-543-6915 Phone : 27-12-348-4246 Carter's Compass... I know I'm on the right track when by deleting code I'm adding functionality.