rodda at kde.org
Tue Jun 17 11:41:56 UTC 2008
(Moving to kdevelop-devel)
On Tuesday 17 June 2008 20:34:14 David Nolden wrote:
> Am Dienstag, 17. Juni 2008 11:36:22 schrieb Hamish Rodda:
> > SVN commit 821376 by rodda:
> > Make the openContext* functions generic
> I'm a bit worried about this commit, because this touches code that is
> really very C++ specific and fragile, and making those functions generic
> might make it complicated fixing bugs within the C++ support in future.
> Also I'm frightened of hard to find regressions, because especially the
> code updating hard to debug. But this is just from the commit messages, no
> time to look at the actual code atm.
I understand that, and of course c++ is the highest priority language.
However what I am doing is really just re-merging the generic parts of the
duchain builders which I've discovered through creating the java duchain.
It's way too much code duplication to just let it bit rot in probably more
than 5 locations, which every other language will face if this code is kept
separated (already, the code was copied from c++ to java, to php). I'm more
than happy to track down any regressions which are found.
This will also lower the barrier to entry for further language support, which
previously was too high.
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?
Refactoring will also make the code easier to understand, and to document for
those working on the code.
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
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? That
will work fine with the current setup. (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, right?)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the KDevelop-devel