It is nice that you think about that :). May be this is just that we have different contexts of use and that we should improve the API by supporting such scenario.
Stef > 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 :( > > > >
