Re: [cdt-dev] Refactoring in CDT

[Tom Ball <tball@xxxxxxxxxx>]

>  - Was there a reason to explain the current design to have the
> refactoring actions within the cdt.UI plugin?

That's what the JDT has, and like a lot of other CDT functionality, the design was copied.  My guess is that the reason the JDT has it in UI is due to the chances of any useful refactoring breaking code -- adding it as an editor enhancement with previews and undo support makes that risk more acceptable to developers who use it.

>  - Any thoughts to how I could solve it without adding the dependency on
> cdt.UI or copying the code?

Cut&paste (really).  You'll find early on that most of the refactoring support only works on C++ code (different AST node types), so it will need major rewriting anyway.  The C++ refactoring code's real value to your project is as sample code.

>  - Are there any plans to refactor the refactoring into another plugin? ;)

Not that I've heard, but I'm not that section's owner.

>  - Would CDT developers be interested in the other refactoring actions
> I'm developing? (even if it doesn't really make sense to propose them
> from the refactoring pop-up menu, but they could be interesting for
> other purposes such as "smart" code (re)generation)

My guess is yes, depending on what the benefit to all CDT users might be compared to the cost of integrating your changes (those sorts of patches tend to be big, and thus a lot of work).  I submitted a small refactoring for 6.0, and found the CDT team to be very supportive and accepting.  It probably helped that I used their existing framework and design patterns as much as possible, and included lots of tests to reduce the risk of adding that feature.

Tom

On Wed, Mar 25, 2009 at 6:48 AM, Simon Chemouil <simon.chemouil@xxxxxxxxxxxxxxxx> wrote:

Hi!

I hope I'm posting to the right place :). I am currently working on an
Eclipse RCP plugin which needs to refactor some C code patterns.

I am already using CDT (cdt.core) for the parsing in another part of the
project, so I know how to retrieve the ICElement/IBinding to call my
refactoring on.


Currently, all refactoring actions I call are meant to be unattended (no
user input -- the refactoring is called at some point without displaying
a refactoring popup and the scope of the refactoring is to be defined
programmatically).

The refactoring actions I need are:
 - global function rename
 - change function signature (breaks type soundness for calls to that
function and variable bounds in function body -- the broken expressions
are to be commented out and a TODO marker put for the programmer to fix
the code manually)
 - change comments preceding a function (doxygen-like comments)
 - delete a global function
 - create a global function (given a signature and a comment)
 - probably change some global variables/structs

Some of these refactoring actions are already available in CDT so I
would have liked to use them.

Unfortunately, it is my understanding that in both CDT 5.0.2 and 6 those
are in the UI plugin and thus using them imply having cdt.ui as a
dependency and the code seems to be bound to UI concepts & objects
(IShellProvider, ISelection, IWorkbench, ...). Since my plugin does
unattended refactoring it may be ran headless (no dependency on
eclipse.UI) so I'm a bit stuck.

It seems to me that the refactoring support and most of the business
logic of refactoring could be in another plugin (cdt.core or
cdt.refactoring) with some API to provide the same level of user
interaction with the user when called from the UI plugin. In fact, the
LTK refactoring itself is independent from UI concerns.


Hence my questions:
 - Was there a reason to explain the current design to have the
refactoring actions within the cdt.UI plugin?
 - Any thoughts to how I could solve it without adding the dependency on
cdt.UI or copying the code?
 - Are there any plans to refactor the refactoring into another plugin? ;)
 - Would CDT developers be interested in the other refactoring actions
I'm developing? (even if it doesn't really make sense to propose them
from the refactoring pop-up menu, but they could be interesting for
other purposes such as "smart" code (re)generation)


Thanks for your help!


Greetings,

--
Simon Chemouil
Anyware Technologies
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev