Bugzilla – Full Text Bug Listing
| Summary: | [generalize type] should use ImportRewrite to avoid duplicate types | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Larry Edelstein <ribs> |
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | minor | ||
| Priority: | P3 | CC: | markus.kell.r |
| Version: | 3.4 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | stalebug | ||
ChangeTypeRefactoring should use ImportRewrite wherever it updates a type.
Complete & compiling example, ready for copy-paste to Package Explorer:
package musicalinstrument;
import shape.EquilateralTriangle;
class Triangle {
private EquilateralTriangle shape; // generalize 'shape' to 'Triangle'
}
package shape;
public class Triangle {
}
package shape;
public class EquilateralTriangle extends Triangle {
}
Expected result:
package musicalinstrument;
class Triangle {
private shape.Triangle shape;
}
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
Build ID: I20080617-2000 Steps To Reproduce: Start with: package shape; class Triangle { ... } package shape; class EquilateralTriangle extends Triangle { ... } package musicalinstrument; class Triangle { private EquilateralTriangle shape; } Say you realize that your musical instrument class, Triangle, representing the little percussion instrument, assumes that the shape of the instrument is an equilateral triangle, when in fact it could be any kind of triangle - scalene, isoceles, etc. So you run the Generalize Type refactoring on the "shape" member variable, and select the Triangle class. You are selecting shapes.Triangle, of course, and it will be imported, so you'll have: package musicalinstrument; import shapes.Triangle; class Triangle { private Triangle shape; } but it won't work - it won't compile - because the type of the member variable is musicalinstrument.Triangle, not shape.Triangle; the import is rendered moot because the class itself has the same name. What you need is for the refactoring to produce this declaration of the member variable: package musicalinstrument; class Triangle { private shape.Triangle shape; } Admittedly it's not going to happen every day. But it happened to me; I have a class called Configuration, and it previously had a member variable declared as the Hibernate Annotations type AnnotationConfiguration; I generalized it to the garden-variety Hibernate Configuration class, and was surprised. (filing this in the UI component, because all the other refactoring bugs I've seen list it that way)