Edit Rename Upload Download Back to Top

Custom Refactorings and Rewrite Editor Usability

The refactoring and rewriting framework has many powerful features but the documentation is brief on some of them while others must be found by using the RB to search itself for likely starting points. We aim to use and help others use these features, extend the RB's refactoring set, etc.

Visit the project's SourceForge pages for news, downloads and to report bugs. These wiki pages are now being used to document the project's content and purpose (the plan is to write a manual in time; meanwhile, use these pages). To suggest an enhancement or report a bug, use the source forge trackers (but scan their lists and these pages first to see if your enhancement is already being discussed). If you add comments or annotated links to these pages, please email Niall Ross (remove spam trap from address before emailing) so I can integrate them into the page.


Summary Project description

This project has several sub-branches

Our latest code may be obtained from the sourceforge pages (older downloads are still on the Custom Refactorings and Rewrite Editor Usability Download page).


Refactoring Browser links

UIUC Refactoring Browser main page

Refactory Refactoring Browser main page By all means add links and/or annotate links here (e.g. to note any that are not up-to-date). I suggest not adding links that are easily reachable from the top-level links given here; if you think it worth pointing out, just annotate the top-level link with what it can reach.


Long-Term Ideas

Beyond the usability improvements suggested above, I see the most valuable future development of the Refactoring Browser framework as lying in combining it with dynamic method wrapping. This is clearly suggested by the RB's own documentation, which speaks of using John Brant's method wrappers for renaming polymorphic methods. Two dynamic frameworks exist (that I know of):

The task of creating a seamless static and dynamic code manipulation framework from these elements is not one to be tacked on to the end of this. At a later time, I will add a link to pages describing where I am going with this.


Project History Overview (CS7 and earlier; for later, see our SourceForge pages)

This project was started at CS3 by Andrew McQuiggin and Niall Ross, and continued at CS5 by Niall Ross, Daniel Vainsencher, Adriaan van Os, Michael Prasse, Aaron Hoffer, Francisco Garau, Michael Bateman and others. CS6 work, some of it off-line, has been continued by Niall Ross, Adriaan van Os, Michael Prasse, Aaron Hoffer, Thomas Koschate and Joseph Pelrine, and tested by Andrew McQuiggin and Marten Feldtmann. We are grateful to John Brant and Don Roberts for providing the RB and answering our questions.

Future CS and/or off-line workwork: for specific tasks, see the future work sections of the above pages. Additionally, there are porting tasks

CS7 Work: method renaming work We also did some minor fixes and refactorings. See Niall Ross' ESUG 2003 report for more details.

CS6 Work: there was an early CS6 release in mid-November 2002 ported our work to RB3.5.2 with some additions. The main release, CS6 RC2 in early December 2002, is the first release that shows the vision for the project. It adds a significant usability functionality to the rewrite tool. A bugfix release, CS6 RC3, was uploaded to the Wiki on 9th March 2003 and to our new SourceForge site a month later. The VW7.1 release was uploaded to the Cincom Open Repository in June.

CS5 Work: Much work was done and ported to both VAST 6.0 and VW/Envy 3. See the above linked pages for details and the foot of the CS5 Projects page for a summary of what we did there (or the conference report available from whysmalltalk).

CS3 Work: Rewrite Editor UI and simple code -> meta utility done for VAST; see the Rewrite Editor page for details.

Refactoring Browser Tests Work: as a side effect of our work, we had to get the RB tests and associated data files from their various locations and grasp how they work, helped by an email from John Brant during the Camp. We will document this on these pages so future users can find things quickly. Adriaan and I sorted out some bit rot in the VA and VW3 Envy map, and wrote a

  proceedThroughError: aMatchableString in: aBlock

method (distinct VA and VW submethod implementations) paralleling John Brant�s #proceedThroughWarning:, to handle Envy-application-scratching obstacles to test completion. We include this in the release download as it may be useful for other tests.

While doing this, we were briefly confused by the bug (I think, a known issue) that VW3 reads a FileStream to the end, fails to read further, exceptions and default resumes. In a test (e.g. an RB test trying to read in a file of test-data code that isn�t on your system yet), this causes the bizarre result that TestRunner shows the test as failing but applying the debug button to it has no effect, because the debugger knows this isn�t a real error and ignores it. As an exercise, we quickly wrote code to make SUnit handle this. In VA, the reverse error occurs. The missing file error insists on throwing up the debugger even inside an SUnitBrowser test run; is this a known issue? (The SUnit team were busy when we saw these effects and we forgot to ask them about it later.)

Dialect-Specific Work: in VA, RB framework windows used to disappear when closing and reopening an image. John has fixed this in RB3.5.2 for the Refactoring Browser. We have extended his fix to the Rewrite Editor and Smalllint windows, all of which now persist when closing and reopening an image, along with their important state. We have also fixed a bug that caused a Refactoring Browser with 'hierarchy' set to get confused on reopening.

These changes were tested by eye, not by SUnit. If anyone knows how to write an SUnit test that checks for persistence across closing and reopening an image, please let me know. :-)


(Written by Niall Ross et al.)


Edit Rename Upload Download Back to Top