Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-core-dev] RE: [Bug 75364] [plan item] Refactoring support

I guess my major concern with text-search is that there is a good 
potential for text search to return more results than you want. One thing 
we've learned in our work on the CDT parser is that parsing is slow and to 
avoid it where possible. By using CDT's index to find the files you are 
really interested in, you will greatly improve your performance, 
especially on large projects.

We're getting off to a slow start with the AST because we want to do it 
right considering all of the clients that could use it and we are very 
concerned about scalability and performance of creating an AST (which is 
why we didn't do it originally). Any advice/help you guys can offer in 
that area would be hugely appreciated :-)

Cheers,
Doug Schaefer, IBM's Technical Lead, Eclipse CDT
Ottawa Lab, IBM Canada, Rational Software Division



Markus.Schorn@xxxxxxxxxxxxx 
Sent by: cdt-core-dev-admin@xxxxxxxxxxx
10/20/2004 05:20 AM
Please respond to
cdt-core-dev


To
Douglas Schaefer/Ottawa/IBM@IBMCA
cc
Michael.Scharf@xxxxxxxxxxxxx, cdt-core-dev@xxxxxxxxxxx
Subject
[cdt-core-dev] RE: [Bug 75364] [plan item] Refactoring support






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.
> 
> 
_______________________________________________
cdt-core-dev mailing list
cdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-core-dev




Back to the top