Re: [Cpptool-develop] Next things ..

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

----- Original Message -----
From: "Andre Baresel" <and...@gm...>
To: "Baptiste Lepilleur" <gai...@fr...>; "CppTool Mailing List"
<Cpp...@li...>
Sent: Saturday, December 21, 2002 8:46 AM
Subject: Re: [Cpptool-develop] Next things ..


> Baptiste Lepilleur wrote:
>
[...]
> >Well, I can't think of one now, but you could get started on the
> >IntroduceExplainingVariable refactoring.
> >
> >While it is not possible at the current time, when the full parser will
be
> >done, we might want to try to guess the return type of the extracted
> >expression instead of asking it to the user.
> >
> >I don't know for you, but I often use this refactoring when dealing with
a
> >long chain of call:
> >
> >contact.getAddress().getPostalCode()
> >=>
> >const Address &address = contact.getAddress();
> >address.getPostalCode();
> >
> >If the type of 'contact' is known (and the class declaration), we should
be
> >able to guess the type of the expression. This will be difficult as it
will
> >require expression analysis and interpretation.
> >
> Yeah I would try, but we need to parse class declarations to collect
> this information isn't it ?

Like I said above, this is not possible at the current time. A full parser
is needed. The current implementation of IntroduceExplainingVariable would
simply do the following things:
- ask the user for the type and name of the extracted expression
- add a variable declaration before the statement in which the expression
appears (may need to add a compound statement)
- replace the extracted expression with a reference to the new locale
variable.

> Since we need to known about a classes members/methods.
> This needs the introduction of new AST-NodeTypes, any suggestions ?

Yes, this will be needed, but let's focus on the method level analysis for
now. There is still much to do and clean up in the current implementation:
ASTNode polymorphism issues, node type features, code rewriter....

Even when we will have a full parser, I don't think that such expression
analysis will not be so high in the priority least as it is only a
convenience. It is fairly difficult to implement and is only a convenience.
There will be much more interresting and useful refactorings to implement
then.

> I'm allready starting to think about this -- so if it's ok for you than
> I will open a new to-do-item
> on the Wiki pages... lets say,
> "Parse method implementation and class declaration"

Parsing for method or function declarations should probably be done while
dealing with variable and attribute declaration. I expect some ambiguity to
appears, much like what happened with the expression and locale variable
declaration.

> Some test example which should work after this extension:
>
> class Name {
>     method_declaration ( ... parameters ...) ; /* optional implementation
*/
> }
>
> method_declaration ( ... parameters ... )
> { /* compound statement parsed using the current parser implementation */
> }
>
> -- Andre