+1 --- Nathan Brown <[EMAIL PROTECTED]> wrote: > +1 > > Guillaume Berche wrote: > > Subject: Extend refactorings to ones that can not be 100% automated > but > > assist programmers in performing remaining manual modifications. > > > > I read a discussion in the archive of this list from jetBrains > people saying > > they see few value to refactorings that can not be automated. I > would like > > to offer a different opinion on this. > > > > In such refactorings the UI support for the refactoring would be > split in 3 > > phase: > > 1. usual preview > > 2. execution of automated transformation > > 3. iteration from the preview screen to the list of required manual > changes. > > > > While this is true that such refactoring are less impressive that > fully > > automated ones, I believe they can still bring much value to the > developer > > because most of the work (usually in identifying necessary changes > to be > > made) is performed automatically. I believe in most situation, the > potential > > benefit of an tool concerns time necessary to perform the > refactoring is > > greatly devoted to identification of changes rather than performing > the > > change itself. I however agree that IDEA with its semantic search > often > > already reduces significantly this time, but I still believe there > are great > > remaining opportunities for improvements. Some examples I > frequently ran > > into with build 638: > > > > Suggestion 1: Move method refactoring for non-static method (for > instance > > up/down in a class/interface hierarchy). > > > > Whereas it can not be 100% automated such a refactoring provides > the > > following benefits: > > - automatically identify dependencies and necessary updates > > - automatically move method declaration > > - support programmers in performing remaining manual modifications. > > > > Suggestion 2: Improvement to method signature change refactoring to > support > > modification of declared exceptions > > > > I would be nice if the method signature change refactoring would > allow the > > programmer to also modify declared exceptions. Then check if > callers catch > > blocks need to be modified (given the actual "surround with > try/catch" this > > should be easy to implement), and list the ones that need manual > > corrections. Then the programmer can apply on those the "surround > with > > try/catch" code generation. > > > > Guillaume. > > > > _______________________________________________ > Eap-features mailing list > [EMAIL PROTECTED] > http://lists.jetbrains.com/mailman/listinfo/eap-features
__________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com _______________________________________________ Eap-features mailing list [EMAIL PROTECTED] http://lists.jetbrains.com/mailman/listinfo/eap-features
