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

[Grzegorz J. <ja...@he...>]

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.

Best regards
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################