[Monodevelop-devel] Improving refactoring after 2.0
monoman at gmail.com
Wed Nov 5 07:49:26 EST 2008
+1. Test-driven design is the way to go with such a complex subsystem.
I foresee some hard spots:
1) UI-decoupling on preview/user-decision
2) Memory-consumption to keep track of all pending changes, and before/after
Also it should be decided if all would be affected files should be loaded in
editor windows, or changes could occur behind-the-scener after user
previewing/deciding, this may bring in some synchronization issues with
other subsystems/addins like the version control one.
About version control integration, it is not common on open source projects,
but where I work currently SVN is configured to demand locking files to be
able to commit changes on them, meaning that eclipse/vs.net keep asking me
if I want to overwrite the locally marked-as-readonly files in the middle of
refactorings, as I never try to guess and lock files prior to working on
them, and I think we should support that too.
Just some thoughts
On Wed, Nov 5, 2008 at 7:11 AM, Mike Krüger <mkrueger at novell.com> wrote:
> 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
> 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 ?
> Monodevelop-devel-list mailing list
> Monodevelop-devel-list at lists.ximian.com
Rafael "Monoman" Teixeira
"I myself am made entirely of flaws, stitched together with good
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Monodevelop-devel-list