7 Apr
2009
7 Apr
'09
7:20 p.m.
Why I thought of having a generic refactoring
interface is because then
we
can even expose it into velocity scripting.
Behind the scenes this
interface
implementation will use various refactoring
components to perform well
defined (high-level) refactoring operations...
You can do the same with small many small components, the difference is
purely at the syntax level:
$refactorings.get('splitDocument').refactor({'criterion' :
'headings',
'headerLevel' : 2})
which is equivalent to:
$refactorings.splitDocument.refactor({'criterion' : 'headings',
'headerLevel' : 2})
vs:
$refactorings.splitDocument({'criterion' : 'headings',
'headerLevel' : 2})
I think that having an umbrella component is bad, since it means that it
needs to be updated for each new refactoring we introduce. And if we
want to allow third party refactorings, then there should be a way to
access refactoring that are not covered by the umbrella.
We should answer questions like:
- Do we need a preview, like Eclipse does?
- How to make them reusable both from XEclipse,
scripting and the web UI?
- How do we customize the refactorings? Passing a map to the main method
is a good solution?
- How to deal with errors? A common problem is insufficient rights.
- Should this be transactional?