[cdt-core-dev] RE: [Bug 75364] [plan item] Refactoring support

[Markus.Schorn@xxxxxxxxxxxxx]

Hi Doug, et al.!

this looks like a good plan to me, despite the fact that it
will take longer than I expected, until I can get my hands 
on the AST.
It's good news that I can plan with an AST-rewriter, it will
pay off in the long run. I was not any more planning with it
to start out with, so the AST-requirments I elaborated must 
be split up in requirements for AST and AST-rewriter.  

I still want to base refactoring on a text-search, and create
AST upon the matches. That way I can cover code (warnings,
text-based refactoring), where the parser fails to create AST 
for. The reason why I plan with such failures are:
 - code that cannot be compiled
 - misconfiguration
 - unsupported language dialects
 - conditional compilation constructs 

Markus.

> -----Original Message-----
> From: Douglas Schaefer [mailto:dschaefe@xxxxxxxxxx] 
> Sent: Monday, October 18, 2004 11:03 PM
> To: Markus.Schorn@xxxxxxxxxxxxx
> Cc: Michael.Scharf@xxxxxxxxxxxxx; cdt-core-dev@xxxxxxxxxxx
> Subject: Re: [Bug 75364] [plan item] Refactoring support
> 
> Hi Markus,
> 
> Thanks for your list of requirements. I will go through them 
> and give you detailed feedback over the next couple of days.
> 
> I've spent a little time looking at JDT and how it does 
> refactoring relative to it's AST (DOM) and ASTRewrite 
> components. I am coming to the conclusion that this is a good 
> architecture to follow. Here are the main points I'd like to 
> see in place for the CDT in relation to the AST, Search, and 
> Refactoring:
> 
> - Be able to create an AST for a translation unit. This is 
> pretty basic but it needs to take into account build settings 
> which we have been gaining experience with our work in CDT 2.0.
> - Be able to invoke the CDT search engine to find references 
> and declarations of named types, functions, and variables. 
> The results should be in the form of a list of translation 
> units with location information so that we can quickly find 
> the AST nodes.
> - A rewrite capability similar to the JDT that takes in 
> requests for AST changes and creates TextEdit objects that 
> will affect those changes. We do not have to support people 
> changing the AST willy nilly since the clients can use the 
> rewriter directly. This will allow us to control which 
> changes we accept since some will take longer to implement 
> than others.
> 
> I will write up a walkthrough of JDT's Inline Constant 
> refactoring that I did to show how things work there. It 
> might be a good idea to look at some more since it appears 
> they use different techniques for different refactorings.
> 
> String search based refactoring is similar to the rename 
> refactoring we put in CDT 2.0. It is a great place to start 
> to figure out the interactions with the LTK and search engine.
> 
> AST2 is still pretty young and doesn't have parser support 
> yet. We are a few weeks away from that becoming usable. We 
> may need to think a bit about the best way to get you started.
> 
> I am also copying the cdt-core-dev list to make sure we keep 
> our work out in the open :-)
> 
> Cheers,
> Doug Schaefer, IBM's Technical Lead, Eclipse CDT Ottawa Lab, 
> IBM Canada, Rational Software Division
> 
> 
> 
> Markus.Schorn@xxxxxxxxxxxxx
> 10/18/2004 10:01 AM
> 
> To
> Douglas Schaefer/Ottawa/IBM@IBMCA
> cc
> John Camelon/Ottawa/IBM@IBMCA, Michael.Scharf@xxxxxxxxxxxxx 
> Subject [Bug 75364] [plan item] Refactoring support
> 
> 
> 
> 
> 
> 
> Hi Doug,
> I have compiled a list of what I'd like to be able to read 
> out of the AST (https://bugs.eclipse.org/bugs/show_bug.cgi?id=75364),
> I appreciate any feedback on it.
> 
> To get warmed up I wrote a string-search-based rename 
> refactoring that work's pretty decently. Now I'd like to 
> integrate the AST parser to implement the additional checks 
> on the string matches.
> Is it a good idea to code against the current AST2 interface, 
> or am I better off waiting for a later or final version?
> 
> Markus.
> 
>