KDev codemodel/refactoring API

[Roberto Raggi]

Hi!

I'm positive you don't want to use the KDev' codemodel for that. I mean the 
code model is _not_ designed for things like code refactoring. Code 
refactoring requires a lot more information, and we don't have any plan to 
add the required stuff in our code model.

I don't know your plan for the code refactoring engine, but we already have 
something in kdev-pg (The KDevelop Parser Generator), so I'm positive we will 
be able to provide code refactoring for C# and Java pretty soon.

The idea is to use the (kdev-pg generated) AST and text-replacement stuff 
provided by the kdev-pg runtime library
http://websvn.kde.org/branches/work/kdevelop-pg/include/kdev-pg-replacement.h?rev=566286&view=markup

For instance, we use something very similar to kdev-pg-replacement in 
Trolltech's qt3to4 (the Qt4 porting tool). Search for "TextReplacement" in
http://websvn.kde.org/trunk/qt-copy/tools/porting/src/

// have fun
ciao robe

On Friday 04 August 2006 12:32, Tom wrote:
> Hi all,
>
> For my Google SoC project I am attempting to implement a language agnostic
> Refactoring API for KDevelop, loosely based upon a similar architecture
> found in MonoDevelop.
>
> Early on in the project I discovered some inadequacies in the current KDev
> codemodel and set about creating my own "dummy" model to base my API upon.
> This included a good deal more meta data describing the nature of the code
> objects. It was assumed that this could provide some good direction to nay
> subsequent modifications of the current KDev codemodel.
>
> Having explored the MonoDevelop refactoring architecture in great depth it
> is clear it's own limitations are founded on accommodating its own
> codemodel - a mixture of a dedicated codemodel and the C# library
> CodeMember etc.
>
> In short a source file is parsed into the dedicated MD codemodel, this
> allows a means to discover the coordinates of an object or part of an
> object within the source file via line/col. A refactoring can then be
> applied to the area in question typically using some regexp's and dirty
> edits. This is all made to an editable copy of the source file and is then
> committed to disk.
>
> It has become apparent that porting this system may not produce an ideal
> refactoring architecture. If I am already making assumptions using a 'dummy
> codemodel' would it not be better to make more assumption based upon an
> even more powerful system. Ideally the capability to parse a file into a
> given codemodel/AST, edit the code model to make changes to the code's
> metadata and then regenerate the code from the codemodel/AST? Changes to
> method bodies or initialisation statements would still need to be done via
> strings and editing using regexps, but this would appear a far more
> streamlined approach, clearly separating the responsibilities of the
> refactoring API and the codemodel.
>
> Discussions in #kdevelop would suggest there is no general facility/API in
> kdevelop4 for manipulating the KTextEditor component programmatically and
> any edits would have to be done manually via Qt and resolve a file to a
> bunch of lines in a QStringList. It's clear a more comprehensive solution
> would be a benefit to all.
>
> I would appreciate any feedback discussing if this sounds possible and if
> it could be a likely future development.
>
> cheers
>
> ventoux
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at barney.cs.uni-potsdam.de
> http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel

-- 
Roberto Raggi - roberto at kdevelop.org
KDevelop http://www.kdevelop.org