I've been thinking about this... because the refactoring api can be a pain to handle (at least for me) in some cases, specially when I'm working with an AST node... because in the node it's all (or almost all) the information needed for the api and I started to ask me... why I'm always opening the node to extract all the strings just to use the Refactorings? I don't like to do that, and I think that time to time we have that problem and ended repeating code... I was thinking in change the refactoring API to accept an AST node, but it's not true that we have the node in the hand all the time we want to use it, and adding more entry points could complex the api. Also if we convert a node in a model for the refactors there are some cases where the information isn't complete in the node, by example to rename a variable you need the new name... and that is not present in the node but needed for the refactor... so is not that simple to make them an inocent model... Then I thought that I can use a new object that takes the node, and creates the refactors needed (similar to NautilusRefactoring using an ast node), but in this model I think that we are doing yet another work around and not a real solution... The other day Guille points me that maybe I should think that the refactoring API is kind of ok... and maybe the nodes could give me the refactors or an almost configured refactor... since they have (almost all) the information. So... I was thinking in this approach, it could be a solution to all the strings handling, and it kind of make sense that the node knows the refactors that apllies and how to construct it with the information needed. A number of ideas... and I would like to discuss about them, maybe here is someone who has the same problem and arrived to a different solution, so I would like to exchange opinions and improve that part that I think we are working around but not solving :(