New things being worked on

[Roberto Raggi]

Hi Alexander,

Catalog is not that great ;) the big problem of Catalog is "IT IS TAG BASED"!! 
and trust me it's very bad to use TAG based storage to implement "High level" 
features like Code refactoring.  I mean the only information you have to 
compute "local attributes" is the "name" of the parent scope, unfortunately 
that's not good enough. What I would like to have is an OO interface, like 
the "Reflection API" of Java, so an interface similar to KDevelop::CodeModel, 
but stored in an OO DB.

ciao robe


On Saturday 18 December 2004 00:19, Alexander Dymo wrote:
> 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 :)