Future of refactorings

[Milian Wolff]

On Friday, July 31, 2015 12:19:45 AM Maciej Poleski wrote:
> Hi
> 
> At least both of us see that not everything is as fluent as it should be. I
> was a bit misled by lots of blogs describing libTooling as a universal
> basis for refactoring tools. It turns out that not everything is as simple
> as it looked like.
> 
> Ideas I had at the beginning are not best fit for capabilities we have here.
> We should think again about possibilities being aware that e.g. ability to
> connect information between TUs is limited. "local refactorings" seems
> good, but what does it mean?
> 
> I was thinking about possible implementation of de-inliner (header ->
> implementation). What is worrying is that when we take AST node, we are
> unable to make modifications and serialize it back to source code. We can
> only take its source (range to be precise). Then we work with text and have
> no further help with it. Of course we can "cut" implementation from header
> (and leave semicolon instead), get implementation file (using buddy feature
> from KDevelop), prepare new declaration here somehow (traversing AST tree
> up to root and collecting names of nested DeclContexts...) and put
> previously cut code here. Very dumb, very context-insensitive, lack of any
> semantic interpretation - we are working on text. If implementation depends
> somehow on context of header (namespaces, ...) we are missing this
> dependency. I'm not sure if such functionality is satisfying for us.
> 
> Give more examples of tools which may be interesting. We should try to
> maximize effect (usefulness). What other refactorings can be useful for us
> (programmers)? Let's try to prepare some set of interesting tools. We can
> then order them depending on do-ability, usefulness, other traits. I'm a
> bit sucked from ideas for now, as my ideas burned on libTooling(/Clang
> compiler) API.

I agree with the above, and like the suggestions we got from Sven and Andreas already. I've started to 
create a tech base wiki page for collecting ideas. Please extend it as you seem fit, but also include before/
after code snippets to understand what should be done:

https://techbase.kde.org/Projects/kdev-clang/RefactoringTools#Ideas_for_Refactoring_Tools

> PS
> What is very noticeable for me is that libTooling is a great tool to
> introspect existing code. I can't imagine other approach yielding so
> precise information about code. Maybe it is not the best foundation for
> general purpose refactorings (as opposed to "special purpose"
> refactorings), but it has extreme capabilities to extract information. I
> have feeling that libTooling could ultimately power the whole C++ IDE, with
> very precise information about code. Even tool consisting of only two
> parts: text editor and Clang could be very powerful.

We get a lot of power from libclang (the C-API) already, and I'm quite happy with that.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150801/34ecd228/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150801/34ecd228/attachment-0001.sig>