[Monodevelop-devel] Improving refactoring after 2.0

[Michael Hutchinson]

On Wed, Nov 5, 2008 at 5:11 AM, Mike Krüger <mkrueger at novell.com> wrote:
> Hi
>
> After the next release I want to improve refactoring.
> Currently we only have rename as refactoring operation. Generally I want
> to do refactoring a bit different than it is now.
>
> I want a refactoring infrastructure that allows the user to preview all
> changes that are done in the refactoring step (see eclipse for an
> example).

DevExpress Refactor Pro has some nice previews within the editor, with
arrows and highlighting and stuff.

> I'll need to extend/change the current refactoring infrastructure for
> this. And one of the goals for the new one is: unit test support. The
> new code completion infrastructure is tested with unit tests and I think
> that this has improved the code completion correctness greatly.
>
> Any thoughts/inputs here ?

I'm interested in a few different things:

* Cross-project/language aspects of refactoring. For example, if an
identifier is renamed in a C# project, it may need to be renamed in a
dependent VB project or in ASP.NET or XAML files. Unit testing of
these will be an interesting challenge...

* Non-.NET refactoring hooks -- it should be possible to use some of
the infrastructure (at least) for C/C++ or Python refactoring, for
example.

* Extensibility -- how easy will it be to build more "complex"
refactorings? It would be interesting to catalogue all the
refactorings provided by popular IDEs and Addins (VS, Eclipse,
Resharper, DevExpress Refactor Pro etc) and try to break them up into
more primitive operations, so that languages can get the high-level
operations for free by implementing only the low-level operations. I
know we have something like this already, but I think it'd be good to
re-evaluate the primitives in light of all of the high-level
operations we might want to implement.

* Indexing -- for renaming operations (and "find all references") our
performance is currently dire. It might be worth having an index to
make these faster.

I don't have any ideas right now on how these should be done, but I
think it's important to take them into consideration  :-)

-- 
Michael Hutchinson
http://mjhutchinson.com