zwabel+kde at gmail.com
Tue Jun 17 12:29:08 UTC 2008
Am Dienstag, 17. Juni 2008 13:41:56 schrieb Hamish Rodda:
> I'm hoping that this process will make the code less fragile, and probably
> expose a few bugs along the way. For example, of the various openContext
> varieties in c++, some call editor->findRange, and some call editor-
> >findRangeForContext; shouldn't they all be calling findRangeForContext?
Hmm yep that's probably true, unless that hack had a special reason.
> Refactoring will also make the code easier to understand, and to document
> for those working on the code.
I agree, I just fear that it will throw my effort to make the
parsing "reliable" back a bit, because the count of bugs in C++ support is
increased again instead of sinking constantly.
> Fixing bugs with the code should not be much harder than if all of the
> logic were in the one class as currently, in fact I think it is even a bit
> more object-oriented now given that the visitors are a bit more separated
> from the parser state.
It just won't be easily possible to fix problems in the C++ support without
possibly breaking other languages.
> The only issue for working on the c++ support now is that you'll have to
> work with those files as well as the c++ specific files, and it is a little
> annoying that you have to install them before you compile kdevelop (and
> error messages open the installed include, that I consider a bug worth
> fixing, by using knowledge from the build system when we open files and
> preferentially opening the original source file not the installed version).
> > Also I'm planning to merge the use-builder and the
> > declaration/context-builder because the 2 iterations are too slow, so
> > please take that into account while generalizing. :)
> Ok, by layering on top the use builder onto the declaration builder?
> (Are you sure that it's not a
> premature optimisation to do that, because most likely the persistent
> duchain store will make 90-99% of parsing happen only on rare occasions,
I'd like to make use-building the default at some point, so it would be
senseless having that additional run through the complete AST. And we will
always be doing a lot of parsing, don't worry about that. For example when
you change a header, you will have to reparse all the files that recursively
include it, if the change was significant.
Anyway, in general I agree with you that generic code should be shared, but
there is just cases where generalization makes everything more complicated
then bringing a benefit(Having worked a lot on the DUChain I know what I'm
talking about). Even the splitting between Context-/ Type-/ and
Declaration-builder has sometimes been problematic, because they are not
independent, and the way they interact is hard to track. Well, that's enough
of whining for now. Let's better try fixing kdevelop. :)
More information about the KDevelop-devel