[Monodevelop-devel] Improving refactoring after 2.0

[Lluis Sanchez Gual]

El dl 10 de 11 de 2008 a les 08:53 +0100, en/na Mike Krüger va escriure:
> Hi
> 
> > 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 ?

Yes, but it is not a priority right now.

> 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.

Maybe the core MD team won't be able to provide support for languages
other than C#, but maybe somebody else wants to contribute it.

> 
> 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.

In some cases, a warning will be enough. For example, the user should be
able to run Find References, but the results list could include a
warning saying that project XXX could not be searched.

Even Rename Member should be allowed IMO. In the preview window it would
show a warning about a projects whose languages does not support
renaming, but it should allow renaming in those that support it.

Lluis.