Bugzilla – Full Text Bug Listing
| Summary: | New Refactoring: Hide/Create Delegate [refactoring] | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Leon J. Breedt <ljb> |
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | dirk_baeumer |
| Version: | 2.0 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Leon J. Breedt
we can't do it for 2.0 unless we get external help if someone can give me a pointer to an existing similar refactoring to look at, i'd be willing to dig into it. also, is refactoring a moving target (i.e. which builds' source should i be working on?) We don't have a compareable refactoring but a good general starting point is the implementation of the Self Encapsulate Field refactoring. It is in org.eclipse.jdt.internal.corext.refactoring.sef. Currently only the AST is public API. The rest of the refactoring stuff is still internal. There are plans to make it API > 2.0. However the changes are high that most of the internal API is kept stable for 2.0. We are pretty much done with the refactorings we want to implement and the internal API has been stable since 6 weeks. So I encourage you to give it a try. Simply use the internal API. But be aware that we only accept contributions with test cases <g>. There are two project on the Eclipse CVS server that help you to write refactoring tests: org.eclipse.jdt.ui.test and org.eclipse.jdt.ui.tests.refactoring. Looking forward to hearing from you regarding packaging, should I implement it in its own package? i see that a lot of other refactorings are in shared packages, i'd prefer to put it in a package like org.eclipse.jdt.internal.corext.refactoring.delegate. additional comments on how the two actions provided should work: >> Create Delegate Action Validity: Selected field(s) non-primitive. Selected field(s) NOT externally visible (private). Create delegate adds delegate methods to owner class. Which delegate methods are added can be selected by user (similar to override methods). >> Hide Delegate Refactoring Action Validity: Selected field(s) non-primitive. Selected field(s) are externally visible outside of the declaring class: have getter. Should we allow public, protected, package as well? Hide Delegate removes getter (and changes field access to private) and creates delegate methods in owner class to access referenced methods of field(s). * All compilation units in the search space (project? workspace?) which accessed methods of field(s) are modified to access delegate methods of the owner class. Delegate methods have the exact same name as methods of the member, or the same name but with a user-supplied prefix. Errors: * If new delegate method has naming clash with existing method in owner class. * If compilation unit in search space used a field of the newly hidden field(s) and not a method...or should we just create accessors for these as well? * If unit in search space just grabbed a reference and didn't use a method of the member immediately...later on when actual methods are called we don't have a reference to the owner class. Yes, start with your own package. If we decide to integrate it into another
package we can use the move refactoring ;-)).
Create Delegate:
- validation: field not visible and there aren't any getter and setter
methods for the private field.
Hide Delegate:
- in a first implementation I would only allow hide delegate on fields that
are private and have a visible getter method. If a user wants to use hide
delegate on public fields than he first have to use self encapsulate field.
- to search for all references to an element using the right scope have a look
at class RefactoringScopeFactory.
- Errors:
o the new method can also overload an existing method and change the
semantic of the program without producing a compile error. But for the
start I would ignore that case.
o flagging the second and third case as an error is fine for me. IMO they
are seldom cases anyway.
Just to let you know: I am on vacation the next week ;-).
[refactoring] No action planned for 2.1. Bug is tagged as help wanted Create delegate is in place for 2.1. Hide delegate could be done via inline method. No further action planned. |