New things being worked on
Alexander Dymo
adymo at mksat.net
Sat Dec 18 23:13:03 UTC 2004
On Friday 17 December 2004 19:02, Roberto Raggi wrote:
> - a new Code Model - I would like to merge Catalog and CodeModel, maybe
Well, I'd just personally like Catalog to become more like CodeModel.
For that to work we need just several classes like
template<class Tag> NamespaceModel,
template<class Tag> ClassModel,
template<class Tag> FunctionModel,
template<class Tag> AttributeModel,
template<class Tag> VariableModel,
etc.
For now each language should define them by itself
(cpp_tags.h for example). We can have generic set of such classes (a model)
and at the same time it would be easy for each language support to subclass
those model classes and provide their own features.
I feel that cpp refactoring can be implemented much easier with Catalog
because CodeModel currently has some disadvantages:
- it's harder to navigate it than Catalog
- it can take a lot of memory when refactoring information (occurences of
symbol in the code, for example) is collected
- it does not offer persistant "pointers" to the code model objects - after
reparsing a file, for example, FunctionModel object for void someFun() will be
different from the FunctionModel before the parsing. This adds a lot of
problems when tracking for changes in symbols (example: class wizard, notably
function combo and old ns/class/function combos too)
So Roberto, what do you think if we write CodeModel-like functions operating
with Catalog.
<flame>
Catalog is great :)
</flame>
> using Lucene(??)
Mathieu Chouinard pointed us at qdbm, he's trying to port catalog to it atm.
Looks like it doesn't have performance penalties of bdb. It seems it's
possible to create databases in memory w/o much troubles with it if we decide
that project symbol store should be kept in memory.
> I hope to have time to review/update the code I already have :)
I can't wait for Qt4 beta to join you :)
--
Alexander Dymo
ICST Department, National University of Shipbuilding, Mykolayiv, Ukraine
More information about the KDevelop-devel
mailing list