Re: [Cpptool-develop] checkout

[Baptiste L. <gai...@fr...>]

----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Monday, October 28, 2002 6:02 PM
Subject: [Cpptool-develop] checkout

[...]
> I would strongly suggest that we stop adding functionality at this point,
> and thoroughly test what we have so far. Any comments?

I don't agree. The parsing base is already fairly good (it can parse a lot
of sources). I'm trying to have a working refactoring as soon as possible
(see below for the reason).

My current toward testing is:
- If I find a bug, don't fix it until there is a test case for it (the
'switch' bug is an example of this).
- If I have any doubt weither a bug is in the code I'm testing or in a
'base' used by the code, add test for the 'base'.
- Test complex stuffs
- When testing assumes that your 'base' is working (it has its one test).
For example, when testing VariableDeclCollector, a specialization of
VariableDeclVisitor, I only tested for the added functionnalities.

The parse test coverage is already fairly good. Only a few parser don't have
UT yet, and they are fairly trivial. astdump seems to indicates they work
somewhat as expected. The *core* part of the parser is the
VariableDeclMutator (which is ill named since it is a parser...). This is
the inovative part as it recognize a variable declaration without any
complex analysis, that's one of the real breakthough of my approach to
parsing C++. This piece of code is already reasonnably tested (though not
completly).

What I'm targetting now is getting one or two refactorings to work. Once we
have something working reasonnably well (I'm thinking of RenameTemp with
scope), we can release it to the 'world' and show that our approach is
'working'. A proof of concept if you want. This should help attracting more
people on this project, especially since it's so simple...

rfta is what I expect to become the 'refactoring' engine (mid term). For now
it does refactoring and source rewritting (and some bit of parsing). The
current (untested) implementation uses a TextDocument as input and output
(an abstraction of the source container in the IDE), and does the full cycle
of parsing, analysing (temporary declaration location, temporary
occurrences) and transforming (replacing the temporary name).

We're working on an open-source project and time is precious (at least mine
is ;-) ). Being able to release something quickly is a great motivational
factor. The exposure you get with a release is way greater that any set of
tests you can build (that why open-source works). I also have  some other
projects that are in the background for now, but will need to be worked on
soon (need cppunit release, CppUnit 2.0...).

If there is some particular area of the code you would like me to explain,
let me know. A lot of the code is somewhat crude, but then I expect a lot
refactoring to occurs when a complete parser is implemented (parsing for
parameter, attribute, return type... is a lot like parsing for variable
declaration).

Baptiste.
>
> Sven.
>
> --
> Sven Reichard
> Dept. of Math. Sci.
> University of Delaware
> rei...@ma...
---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/