Summary: | [extract interface] support extracting methods to existing interfaces [refactoring] | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | nicola guidotto <nicola.guidotto> |
Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | nicola.guidotto |
Version: | 3.2 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
nicola guidotto
2005-08-19 05:40:59 EDT
I am not entirely sure what your scenario is. As far as I understand, you would like Extract Interface to be more incremental. That is, the ability to extract methods to an already existing and implemented interface (therefore the search button for classes, right?). If an already existing interface is gets selected, the UI would only allow to check additional methods to be extracted. After this step, no additional UI is necessary (why compare-merge and a wizard?) But I like the idea as well. (In reply to comment #1) > I am not entirely sure what your scenario is. As far as I understand, you > would like Extract Interface to be more incremental. That is, the ability to > extract methods to an already existing and implemented interface (therefore > the search button for classes, right?). > If an already existing interface is gets selected, the UI would only allow to > check additional methods to be extracted. After this step, no additional UI is > necessary (why compare-merge and a wizard?) > But I like the idea as well. Sure! That's right. Incremental is exatly what I'm looking for. But consider that we are refactoring so the UI should be flexible (or very interactive) to allow possibly syntax violations be solved inplace or, at least, after the end of the UI Dialog. Consider the case where I change the return type of a "void MyMethod()", and the "old" method definition still stay in the Interface to be updated. I should update the "old" method signature (old return type: void) with the "new" one (e.g. new return type: int), without losing anything like the Exceptions clause. That's because I suggest the "compare-merge" approach available in the "Team->Compare". In general, the incremental approach is more attractive at all, so please abuse about it every where, especially in the refactoring tools. ;) And probably the 3.1.1 release could be more attractive, instead the more later 3.2, if it may be possible... Thank's. The scenario you are describing is not a refactoring. Refactorings are behavior-preserving code transformations from a consistent pre-state to a consistent after-state. We are not abandoning this principle. The refactoring Change Method Signature probably helps for the case described above. (In reply to comment #3) > The scenario you are describing is not a refactoring. Refactorings are > behavior-preserving code transformations from a consistent pre-state to a > consistent after-state. We are not abandoning this principle. > The refactoring Change Method Signature probably helps for the case described > above. You are ok. Respecting the refactoring definition, it seems that the UI cannot allow the interface extraction incremental approach for that case. I have post not appropriate case. Sorry. |