Community
Participate
Working Groups
I wanted to write a refactoring for which I needed to find out many of the same things as Extract Method would need: is a return required? Are there any non-linear paths whose destination is outside of the selected code? If the selection is extracted, what parameters are required? What exceptions are required? I also could do with a couple of things that other refactorings do. Unfortunately, when I looked at the Extract Method code I found that the logic to do these things is quite tangled. Is there any chance of refactoring this code so that a library can be provided so that other refactorings can be written by composing the pieces, without massive copying and pasting or rewriting from nothing? Regards, Lance
We would definitly welcome to have more reusable algorithms. It takes a lot of experience and multiple use cases to find and design such APIs. Our approach has always been to not generalize frameworks or algorithm until we really have the need for it. Designing without direct client needs is mostly not possible. With the API compatibility requirements in Eclipse, it wouldn't be wise to publish an unproven API. So your help and action is not only welcome but essential to make anything happen.
Excellent. What's your preferred way to proceed? Shall I attempt to refactor the Extract Method code to get what I need or just write what I need and give it to you to integrate? Something else? Regards, Lance
It would be great if you could refactor the extract method code at the same time.
I haven't got round to this yet. I needed to start with something simpler. The result is a Hide Delegate refactoring, which can be found at http://code.google.com/p/tane/ (I'm sure you'll forgive my shameless plug :-). If I have time, I'll try to do some work towards this now. Regards, Lance
