[Monodevelop-devel] Improving refactoring after 2.0

Mike Krüger mkrueger at novell.com
Mon Nov 10 02:53:29 EST 2008


> I'm not saying that the current refactoring infrastructure is perfect.
> It is not. Much of it will probably have to be changed if we want to
> support more advanced refactoring operations. But you can't arbitrarily
> drop all current code, ignoring what has been done. We already had some
> bad experiences in MD because of this.

I don't want to drop code. In fact the current one is a good starting
point. There is no need to 'drop' code - I only drop code when there is
no other option. We can use refactoring methods move/rename some stuff -
that's it. I would only drop code if it's GPL or really very different
to refactor the code. 
The code we currently have is something I can work with. 

Something different: But over time we must rewrite ALL GPL code. I think
that's still on our todo list isn't it ?
Refactoring is about improving the design of existing code, not to
rewrite it. In this way it's possible to keep all "information" in the
existing code. With a rewrite you'll loose all knowledge that lead to
the existing code. If possible refactoring is always better.
(But keep in mind that all GPL parts need to be rewritten, except we
change our position here)

> > It starts with clicking on something in the editor window there is a
> > class that builds the context menu and this class controls which
> > operations are valid.
> > 
> > I want:
> > 
> > Split up refactoring a bit to make it clear what each class does.
> > 
> > I intend to split up the "refactoring" feature. Each refactoring
> > operation should be an own class that knows it's responsibilities (based
> > on the resolve result) it knows when it's valid to display in the
> > refactoring context menu.
> > 
> > Then we would've classes like:
> > 
> > Rename
> > ImplicitImplementInterface
> > ExplicitImplementInterface
> > ExtractMethod
> > 
> > etc.
> > 
> > These refactorings should be placed in the addin tree.
> Will those refactoring classes be language-specific?
> For example, the Rename class, there will be a RenameCSharp and a
> RenameVisualBasic? if that's the case, will they share some code?

Thats in the responsibility of the classes they can support csharp and
visualbasic, but I don't think that I'll support more than these two, I
think I personally will stick to C#. Like with the code completion
infrastructure in the csharp binding. It would be possible to use it for
VB.NET and any other language that can produce NRefactory DOM.

When I'm really satisfied with refactoring and the capabilities of
monodevelop (especially text editor and search features) I'll maybe
improve visual basic support or bring any other language backend up to
the C# level. But I don't know if we'll ever reach this point - there is
always more stuff to do and I'm a C# fan :).

Cross language functionality for refactorings is something we need to
factor in but my current 'plan' would be to disallow cross language
refactorings until all refactoring commands are availble for any
languages in the solution - not to allow partial refactorings.


More information about the Monodevelop-devel-list mailing list