Changing the tree for refactoring?

I'm answering an offline question here, because I think it's of reasonably general interest for people using the parser.

Let's look at the desired refactoring of converting DEF VAR a AS CHAR. to DEF VAR a AS CHAR NO-UNDO.. For most such refactorings, I've found it's best to use the parsers to do the analysis, and find exactly which files, lines, and columns of source text need to be changed. With that in hand, slurp the entire source file(s) into a string in memory (or a table of strings, one per line of code), and use normal string processing to make the change and write the file back out. These changes need to be discreet, and they often need to be performed incrementally. (And you need to make the changes toward the end of the source file first, otherwise you mess up the line and column count. :)

A question is whether a better approach would be to modify the syntax tree, and then write the source back out. The problem with that approach is that because of Progress's preprocessor, we aren't in a position to write the source back out from the syntax tree and expect it to have all the preprocessor junk that was in the original source code. This is fine for a rewrite of the code, but it is mostly not acceptable by developers who just want to refactor existing code.

(Could a refactoring system be built which respects the preprocessor junk from the original source code? Yes, but it would be a Large Investment.)

The original offline question was actually how to make changes to the nodes, writing the changes back to the blob, and passing the changes back to prorefactor.jar. The answer is: we won't be doing that! Assuming we we want to fiddle with the syntax tree, and assuming we don't want to do it with Java or any JVM language but we want to do it with ABL (or, say, C#), then the process would be to slurp the binary from proparse.jar into a full hierarchy of Objects in ABL, and do all the desired work with the syntax tree from there.

If there was a series of steps to be taken, then we would use our ABL programs to change the source code for Step One, then maybe re-parse the source code with proparse.jar to fetch a new, refreshed syntax tree to work with for Step Two, etc.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

so what you are saying in a

so what you are saying in a nutshell is proparse.jar => ABL proparse => make change => source file => proparse.jar
rinse, repeat ..


john's picture

Re: nutshell

Right.


ha! I got something right

ha! I got something right !

;)