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

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

--- Grzegorz Jakacki <ja...@he...> wrote:
> On Thu, 20 Mar 2003, James Michael DuPont wrote:
> 
> >
> > --- Grzegorz Jakacki <ja...@he...> wrote:
> > > On Tue, 18 Mar 2003, Stefan Reuther wrote:
> > >
> > > > Hello,
> > > >
> > > > On Mon, Mar 17, 2003 at 04:43:53PM +0800, Grzegorz Jakacki
> wrote:
> > > > > On Fri, 14 Mar 2003, Stefan Reuther wrote:
> > > > > > I think, there are two problems, at least with the parser.
> The
> > > > > > interface consists of two parts, namely the Ptree
> descendants
> > > > > > and their contents.
> > > > > >
> > > > > > 1) Every Ptree descendant has a method "Translate" which
> calls
> > > > > >    a method of Walker. Adding a new Ptree class means
> adding a
> > > > > >    method to Walker.
> > > > >
> > > > > This is the first sign of too little isolation between
> visitor
> > > (Walker)
> > > > > and visited class hierarchy (Ptree and derived classes) ---
> you
> > > cannot
> > > > > extend Ptree hierarchy without modifying Walker code.
> > > >
> > > > I don't think it can be done much different. Ptree and Walker
> > > > have to "know each other".
> > >
> > > I believe that it is possible to introduce a layer in between,
> > > which would encapsualte the actual implementation of Ptree.
> >
> > Exactly my thoughts. We need a cleaner tree.
> > Have you looked at treecc from Rhys W?
> > http://www.southern-storm.com.au/treecc.html
> 
> I had a look. However, I believe that there are no "the best" tree.
> Everybody needs slightly different tree:
> 
>   * OpenC++ MOP needs "lispy" Ptree structure to be able to introduce
>     text chunks into parse tree, which not necessarily are legal C++
>     (i.e. to be able to insert anything using
>     YourMetaclass::TranslateXYZ())
> 
>   * Application which extracts class hierarchy, does not need a tree
>     which exposes function bodies (they possibly have to be parsed,
>     but application is not interested in walking/visiting them at
> all,
>     and they are only a burden in application's walker)
> 
>   * Syntax-highlighting editor needs very detailed hierarchy and even
>     more --- it wants to be able to store annotations with each
>     (or some) nodes.
> 
> What I have in mind for all those examples above is one C++ parser
> and
> three instances of intermediate layer --- each of which adapts
> (on-the-fly) the tree "view" to the application needs. I also believe
> that
> such layers can be somehow "derived" from each other, so if two
> application's requirements are only slightly different, they can
> reuse the
> layer components (which could at some moment constitute a library).
> 
> In general I see two solution when implementing such intermediate
> layer,
> each with its own trade-ofs:
> 
> (1) using "visitor adapters"
> 
>     template <class Adapter>
>     class VisitorAdapterHidingNodeX : public Adapter
>     {
>         virtual void VisitNodeX(NodeX*) {
>              ... creates the translation of NodeX
>              ... and visits it
>         }
>     };
> 
> (2) using traits class for identifying node types visible through
>     particular "view" and using generic visitation to implement
>     visitor (ala boost::variant)
> 
> I am still working on both, I will be glad to post my thoughts when I
> arrive at some substantial conclusions.


Ok, 
As far as I can tell. We have a few data sources , 

1. the preprocessor
2. the lexer
3. the yacc
4. the trees (ast in gcc)
5. the rtl (in gcc)
6. the debug information(in gcc)

All of these are just producing messages.
we need to have a callback filtering system so that the user can
register and subscribe to get the information needed. That will
predicate a identifier system that allows addressing of any part of the
system with an identifier.

This query system could be just a set of callbacks, each callback would
be a differnet type of function.

of course that could be made into a set of classes with methods you can
override. Maybe even a generic function that would allow you to get a
fully instanciated object of a given type.

The treecc is good for defining all the types of nodes. the question of
limiting the view and scope of data is a separate one.

mike

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

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com