KDev codemodel/refactoring API

[Adam Treat]

On Friday 04 August 2006 9:40 am, Roberto Raggi wrote:
> 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

Roberto, how much of an error would it be to just store the actual AST with 
line information and type information rather than the codemodel?  I know it 
would probably be a hit to memory and it is not as nice to interact with, but 
it has two MARKED advantages that I can see:

1.  Our parsers already generate it and we don't need to worry about 
integrating different languages AST.  They are generated from the parsers 
with perhaps a slight modification to make the AST objects inherit 
KDevCodeModelItem.  Problem solved.

2.  All information that is generated by the parser is kept around.  We don't 
have any binding process except adding on type information.  We don't have to 
worry about what the codemodel should look like.

The biggest problem is the hit to memory, but we already keep around the AST 
for the current file for a limited time.  I wonder how much of a memory 
difference it would make.

> 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/

I wonder if your C++ parser in kdevelop has forked very badly from the one you 
use for qt3to4, qt-jambi generator and the LSB standard generator... ?

Either way, we need to figure out what we are going to do about the 
codemodel's for Java and C# as well as what we're going to do with the 
codemodel/binder in C++.

Adam

> 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