[Opencxx-users] Re: [opencxx] Let's break OpenC++ up

[James M. D. <mdu...@ya...>]

--- Stefan Reuther <sr...@ma...> wrote:
> On Mon, Apr 14, 2003 at 04:32:57AM -0700, James Michael DuPont wrote:
> > --- Stefan Reuther <sr...@ma...> wrote:
> > > Another possibility would be to put that knowledge into the
> > > Walker interface. Here, we have such a thing for
> > > PtreeDeclaration. Depending upon whether a PtreeDeclaration is a
> > > class declaration ("class foo;"), a name declaration ("int x;")
> > > or a function implementation ("void x() { }"), it nicely
> > > dissects the tree node and calls different functions. "Class"
> > > and "ClassWalker" already seem to do some other parts of this.
> > 
> > The walker has only one problem.
> > It does not only walk, but also has to interpret things.
> > It has to know how to extract the data out of the parser
> > 
> > How do you propose to hide the details of the parser from the
> walker?
> 
> I would not hide the details.
> 
> Someone has to know about the Ptree structure, right? My point
> was making Walker the one who knows it.
> 
> Like this:
>    // users can override this method
>    virtual Ptree* TranslateNamespaceCooked(Ptree* keyword,
>                                            Ptree* name,
>                                            Ptree* content);
>    // this method is called by PtreeNamespace::Translate
>    virtual Ptree* TranslateNamespaceRaw(PtreeNamespace* p) {
>        return TranslateNamespaceCooked(p->Car()    /* "namespace" */,
>                                        p->Second() /* the namespace
> name */,
>                                        p->Third()  /* the contents
> */);
>    }
> 
> I'm not exactly sure, but maybe that's not too flexible (one
> can't inspect a given Ptree except by making a custom Walker and
> calling it).

Ok, that is one way to do this. 

> 
> The other solution,
>   class PtreeNamespace : public Ptree {
>     public:
>       Ptree* GetKeyword() { return Car(); }
>       Ptree* GetName() { return Second(); }
>       Ptree* GetContent() { return Third(); }
>   };
> puts that knowledge into the Ptree itself, which I like, but I
> feel there are performance problems for things like "GetName" in
> a PtreeDeclarator (it has to skip over a number of "*", "&",
> "class::*" and cv-qualifiers to find the name or sub-declarator).
> But maybe that's not at all a problem (caching?).

I like that better. I dont want to have to make two passes to have a
clean model.

> 
> Using handle classes (Grzegorz' way) would definitely work nice,
> but it's a lot of work to implement it.

I dont know yet what the handle classes would look like. The idea
sounds good. In the end we need to have to hide this whole first and
second interface. 

I like the idea of a XML/DOM like structure that also allows for
lookups on the names. Each type of node that we know about gets a
proper c++ class that is attached to the generic node :


so it looks like this :

ptree -->pImp--> TreeClassDecl

the TreeClassDecl is the class that implements the classdecl
information. The ptree is the generic tree. The pImp points to the
TreeClassDecl because you may have to delete and recreate the
implementation class.

what do you think?
mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com