cpptool-develop

[Cpptool-develop] I'm still there - working through all these sources

[Andre B. <and...@gm...>]

I started getting into the sources, but I'm still not usefull for the 
project :-(

i think it will take some time to get all the ideas. However I started 
to play arround with
this Mutator concept and tried to implement this ToDo Item  "Adding a 
variable declaration in
if/while statement" ... not to make this for the public, but this is 
something I can check against
later on, when you Baptiste have checked your sources in.

I got something working, but well, I'm not sure if this is ok and 
there's a question:
The introduction of a new nodetype for the conditions makes some of the 
tests failing, so how is this situation
handled ? Is it ok than to change the tests, too - since the assertion 
only reports the new ast-node-type not
beeing expected.

Another thing is the MaxLODMutator ... In the beginning I stumbled 
accross two things:
- the methods "mutate" and "doMutate" sound like the same action and 
take the same parameters but they
  do completely different things ... I would suggest some better naming 
here ... maybe doMutate is just "doMultipleMutate" ?
- this MaxLODMutatorVisitor, what about that class, is this really needed ?
      As I understand this class is only used to be instanciated in each 
recursion of the mutation operation.
      Is there anything I can't see ? The use of this class confused me 
a little bit. With this class the recursion comes
      Invisible for a person reading the source.... Just my opinion.

I'll next go into these Scope things -
and in parallel i'm still collecting the useful infos from the forum and 
the mailing list.

See you later,
Andre

Re: [Cpptool-develop] I'm still there - working through all these sources

[Sven R. <rei...@ma...>]

On Fri, 13 Dec 2002, Andre Baresel wrote:

> I started getting into the sources, but I'm still not usefull for the 
> project :-(
Take your time :)

> i think it will take some time to get all the ideas. However I started 
> to play arround with
> this Mutator concept and tried to implement this ToDo Item  "Adding a 
> variable declaration in
> if/while statement" ... not to make this for the public, but this is 
> something I can check against
> later on, when you Baptiste have checked your sources in.
> 
> I got something working, but well, I'm not sure if this is ok and 
> there's a question:
> The introduction of a new nodetype for the conditions makes some of the 
> tests failing, so how is this situation
> handled ? Is it ok than to change the tests, too - since the assertion 
> only reports the new ast-node-type not
> beeing expected.

Two things: 
1) I'm not sure if you need a new nodetype for this situation; we have a 
type for variable definitions, which can just be plugged into the 
condition of the if statement.
2) In order not to break existing tests, don't include the new mutator 
into the MaxLODMutator. Then most tests won't know about your addition, 
and pass as before. I would wait changing the existing tests until you 
better understand the whole structure. (You said yourself that you're 
still working on that.)

> 
> Another thing is the MaxLODMutator ... In the beginning I stumbled 
> accross two things:
> - the methods "mutate" and "doMutate" sound like the same action and 
> take the same parameters but they
>   do completely different things ... I would suggest some better naming 
> here ... maybe doMutate is just "doMultipleMutate" ?

I agree that here the code needs to be cleaned up a bit. The two methods 
do different things, both useful. "mutate" can be applied to any node and 
will change the whole subtree rooted at that node. It calls "doMutate" for 
every subnode it encounters, and that method does the actual work.

Maybe we'll rename it to "mutateTree" and "mutateNode"?

We wanted to separate the recursion from what is done to each node. That 
what the Visitor class (and its subclasses) are for. The basic reason is 
that if we were to change the implementation of the AST, we would only 
need to adapt the Visitor classes, and not every single method that works 
recursively.

> - this MaxLODMutatorVisitor, what about that class, is this really needed ?
>       As I understand this class is only used to be instanciated in each 
> recursion of the mutation operation.
>       Is there anything I can't see ? The use of this class confused me 
> a little bit. With this class the recursion comes
>       Invisible for a person reading the source.... Just my opinion.

And that's the idea! If someone wants to change a tree, they don't need to 
know how this change is performed. In the long run, we hope to move more 
functionality from the subclasses up to the Visitor class itself.

> See you later,
> Andre

Bis die Tage,
Sven.


-- 
Sven Reichard
Dept. of Math. Sci.
University of Delaware
rei...@ma...

Re: [Cpptool-develop] I'm still there - working through all these sources

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

----- Original Message -----
From: "Andre Baresel" <and...@gm...>
To: <Cpp...@li...>
Sent: Friday, December 13, 2002 11:10 PM
Subject: [Cpptool-develop] I'm still there - working through all these
sources


> I started getting into the sources, but I'm still not usefull for the
> project :-(
>
> i think it will take some time to get all the ideas. However I started
> to play arround with
> this Mutator concept and tried to implement this ToDo Item  "Adding a
> variable declaration in
> if/while statement" ... not to make this for the public, but this is
> something I can check against
> later on, when you Baptiste have checked your sources in.

With luck, I will be able to commit this evening...

> I got something working, but well, I'm not sure if this is ok and
> there's a question:
> The introduction of a new nodetype for the conditions makes some of the
> tests failing, so how is this situation
> handled ? Is it ok than to change the tests, too - since the assertion
> only reports the new ast-node-type not
> beeing expected.

Some unit tests of the If parser should failed because they expect a
different node type for the condition. Changing the node type in the check
methods should fix the If parser tests. You also get a few tests failing in
ScopeGeneratorTest because of the new declaration that was introduced.

> Another thing is the MaxLODMutator ... In the beginning I stumbled
> accross two things:
> - the methods "mutate" and "doMutate" sound like the same action and
> take the same parameters but they
>   do completely different things ... I would suggest some better naming
> here ... maybe doMutate is just "doMultipleMutate" ?
> - this MaxLODMutatorVisitor, what about that class, is this really needed
?
>       As I understand this class is only used to be instanciated in each
> recursion of the mutation operation.
>       Is there anything I can't see ? The use of this class confused me
> a little bit. With this class the recursion comes
>       Invisible for a person reading the source.... Just my opinion.

The current mutator stuff are a 'hack' to get the stuff working. It is not
very clear to me what it should be exactly. I expect things to become
clearer when we'll have a more complete parser and some form a AST rewriting
(the current mutation scheme prevent the use of polymorphism in ASTNode).

Sven already covered the other points I believe.

> I'll next go into these Scope things -

Don't bother with the current implementation. It's have been completly
rewritten (IdentifierResolver stuffs). It's a lot more simple and easier to
extend, to resolve unqualified identifier as attribute or member function
for example. I'm in the process of adding test for this.

Baptiste.

> and in parallel i'm still collecting the useful infos from the forum and
> the mailing list.
>
> See you later,
> Andre