KDev codemodel/refactoring API

Tom tomajoha at gmail.com
Fri Aug 4 10:32:46 UTC 2006


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




More information about the KDevelop-devel mailing list