Re: [Opencxx-users] Makefile.am fixes

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

On Thu, 11 Sep 2003, Yann Dirson wrote:

> On Thu, Sep 11, 2003 at 09:16:37AM +0800, Grzegorz Jakacki wrote:
> > I see. Go ahead and implement it if you think it is important, but to be
> > honest I don't think it is a cruicial feature. Implementing it involves
> > some maintenance burden (now anybody writting '$libdir' in docs should add
> > a link to directories.html to be consistient; and most likely that person
> > will not do it, because there is no mechanism or process that would
> > require him/her to do so), but we don't change docs often, so I don't see
> > a problem. I would encourage you to rather invest your time in
> > implementing your ideas about walkers, but if you think 'directories.html'
> > is a good thing, go ahead. Provided you get down to walkers afterwards :-)
>
> That's not so much work, so I can do this while we're discussing walker
> issues :)

OK

> > > > > All of this seems to be easily achieved if we can add hooks to the
> > > > > translation of arbitrary language constructs (casts, statements...)
> > > >
> > > > Right. However after you expand the existing walker you need to have a way
> > > > to coerce it back into the old functionality, so that the occ itself and
> > > > legacy applications compile. However this seems doable.
> > >
> > > Hm.  My idea was that without any hooks the behaviour would be the current
> > > one.  But it's surely both more flexible and less intrusive to provide my
> > > own walker in many cases.
> >
> > I think I did not understand what you mean by "adding hooks". Could you
> > elaborate on this?
>
> In the case of TranslateCast what I'd have needed would be a call to some
> user-defined code within TranslateCast().  AFAICT, since TranslateCast()
> calls cannot be tied to a particular class, it could not be done with the
> metaclass mechanism.  I originally thought it could probably be done if we
> could access from the metaprogram, and derive something like the Program
> instance for the file being translated.

I think this would require quite a lot design work. Current MOP models
just classes and barely touches templates and free functions. Program
metaobject is not available to metaprogram via MOP.

> But I now realize that it would be
> mostly similar, but probably less flexible than deriving the walker, so
> let's assume the latter.

I think so.

> In this case, once we're able to use a custom walker, we could add to
> TranslateCast() a call to a BeforeTranslateCast(), which the default walker
> would implement as a no-op, therefore being non-intrusive.  In the case of
> TranslateCast I don't see myself the need for running an additional
> translation, but I'll still use this example, since this is a much simpler
> method that TranslateFunctionImplementation().  A fully hooked TranslateCast
> (simplified by not avoiding useless copies, and probably missing some calls
> to ShallowSubst or similar) would give something like:
>
> Ptree* Walker::TranslateCast(Ptree* exp)
> {
>     Ptree exp2 = BeforeTranslateCast(exp);
>     Ptree* e = exp2->Nth(3);
>     Ptree* e2 = AfterTranslateCastedExpression(Translate(BeforeTranslateCastedExpression(e)));
>     return AfterTranslateCast(new PtreeCastExpr(TranslateCastType(exp2->First()),
>     	       	   		                Ptree::ShallowSubst(e2, e, exp2->Cdr())));
> }
>
> As you see that'd cause in the case of the default walker a large number of
> calls to methods just returning their argument, but that's the simplest way
> of adding hooks that I can see.

Why not something like this:

class MyWalker : public Walker
{
public:
     Ptree* TranslateCast(Ptree* exp)
     {
         Ptree exp2 = BeforeTranslateCast(exp);
         Ptree* e = exp2->Nth(3);
         Ptree* e2 = AfterTranslateCastedExpression(Translate(BeforeTranslateCastedExpression(e)));
         return AfterTranslateCast(new PtreeCastExpr(TranslateCastType(exp2->First()),
     	       	   		                Ptree::ShallowSubst(e2, e, exp2->Cdr())));
     }

     ... BeforeTranslateCast(...) { ... }
     ... AfterTranslateCastedExpression(...) { ... }
     ... AfterTranslateCast(...) { ... }
};

AFAIU you get the same result without adding a hook.

>
>
> > > or to call the current one and manipulate the result Ptree
> > > again (useless copy of (part of) the Ptree).
> >
> > What if you provide your own walker, which derives or delegates to the
> > existing walker? In your implementation of
> > 'YourWalker::TranslateFunctionImplementation()' you could either call the
> > original walker (and possibly postprocess the result) or not call it and
> > do all processing by yourself. Is this what you are looking for?
>
> Yes, the same could possibly be done by pre-processing and post-processing
> the Ptrees manipulated by the default walker, and I now realize that it
> would be much more lightweight to do so than to add all those hooks.

Looks like we came to similar conclusions.

The code that I wrote above works, but it violates Liskov Substitution
Principle --- the user cannot be sure about the behaviour of member
function 'TranslateCast()' when it is called via Walker*.

The better approach requires separating implementation and interface of
Walker, e.g.:

    class Walker
    {
        ... interface only, all functions pure virtual, no ctor, virtual dtor
    };

    class OpencxxWalker : public Walker
    {
        ... guts of present Walker
    };

(this was suggested some time ago by guys from VFiasco project, whom BTW I
still own a long reply to very insighful e-mail).

With this in place we could do:

    class MyWalker : public Walker
    {
    private:
        OpencxxWalker impl_;
    public:
        ... delegate all functions to impl_ except TranslateCast
    };

This agrees with LSP, but requires lots of work to delegate all the member
functions. However this should work OK:

    class OpencxxWalker : virtual public Walker { ... }
                          ^^^^^^^

    class MyWalker : virtual public Walker
                   , private OpencxxWalker
    {
        Ptree* TranslateCast(Ptree*) { ... }
    };


I think this change would go along well with Walker factory being
implemented by Vladimir --- after the code is fixed to use factory, the only
place where we need to make it aware of OpencxxWalker is the factory class.

BR
GJ

##################################################################
# 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. #
##################################################################